fix(networkstream): charge the childrenMap key and escape containerID in the estimate (SUB-7786)

Addresses CodeRabbit's childrenMap-key finding. A child's comm is emitted TWICE --
as its own field and inside the parent's childrenMap key, which CommPID.MarshalText
renders as comm<U+241F>pid -- and the estimate charged it once, funding the second
copy out of per-node slack. estimateTreeBytes also charged containerID with a bare
len(), three lines above a comment saying never to do that; it was the last one.

Neither is reachable in production: comm is only ever 15 bytes because every source
is a kernel TASK_COMM_LEN buffer (eBPF GetComm, procfs stat.Comm), and container IDs
are hex. Measured at that bound the old accounting stays positive by +170 to +7291,
so CodeRabbit's Major severity is overstated -- I could not reproduce an underestimate
with a 15-byte comm. But the estimate is a BOUND, and it must not rest on an
invariant nothing in this repo enforces: remove the kernel's comm limit and the old
accounting runs 48% under (est 1,323,856 vs 2,531,171 marshalled), which is exactly
the silent over-limit message the budget exists to prevent.

Two corrections to the finding: the CommPID separator is U+241F (3 bytes), not '/',
and the deficit needs a fully-populated node, not any node.

The guard tests could not have caught this -- their children set four fields, so the
slack was never consumed; 200k randomised trees found nothing. The generator now
builds fully-populated children with escape-heavy 15-byte comms, and the table adds
the cases that actually discriminate (unbounded comm, both child shapes, escape-heavy
containerID), all three verified to fail without the fix.

Recalibrated: a realistic 10-node chain now estimates 5683 (was 5102, ~33% over
marshalled), so the budget holds ~461 trees rather than ~513. Still 1.6x the largest
batch observed, and the 283-connection worst case still ships every tree.

Two pre-existing assertions had tight constants tied to the old per-node accounting;
both now state their intent proportionally instead.

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