fix(networkstream): calibrate the tree budget against measured production traffic (SUB-7786)

The 1.5 MiB budget was picked from arithmetic, and it was wrong: it binds at
213 of 283 trees, and 283 connections is the largest batch ever observed in
production. It would therefore clip trees routinely on the busiest nodes --
degrading exactly the attribution this work adds -- while the payload at that
point is only 48% of the 5 MiB limit.

Recalibrated to 2.5 MiB using measured inputs rather than assumptions. The
reputation consumer gives the missing number: network_reputation_events_in_total
over the topic's message count puts a batch at ~42 connections in prod-eu (~32 in
prod-us), which against a 29 KB mean message makes a connection ~530 bytes of JSON
without its tree. Taking the worst case the budget exists for -- every connection
from a distinct process, so trees scale 1:1 -- 283 connections with p90 (~7 KB)
trees now ships all 283 trees at 2.50 MB after base64, 48% of the limit. The
budget binds above ~360 distinct processes at p90 and ~1280 at median, so it stays
a safety valve rather than a routine limiter.

TestBuildWireStream_ObservedWorstCaseFitsBudget pins the calibration itself and
fails at 1.5 MiB, so a future change cannot silently start clipping observed
traffic.

Also fixes the test helper that made the original numbers untrustworthy: it piled
the whole target size into one command line, which the 1 KB cap then truncated, so
it produced ~1.2 KB trees however large a size it was asked for -- and the
calibration test passed at both budgets because of it. It now builds a chain the
way a real tree gets big, and TestBigTree_ReachesRequestedSize keeps it honest.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Alon <alon@armosec.io>