docs(ladder): the ring's documented worst case was 10× low

[thevoiceguy]

DESIGN_SIP_LADDER.md §3.2 published the ring's worst case at defaults as
50 calls × 64 messages × ~1.5 KB ≈ 4.8 MB. That is arithmetic over the
completed-call window alone — it drops the MAX_PENDING (256) and
MAX_LIVE (512) populations the same section introduces thirteen lines
earlier.

The code was never wrong: crates/telemetry/src/sip_ring.rs states the bound
as (MAX_PENDING + MAX_LIVE + cap_calls) × cap_messages entries. So this is
prose drift in the design note, not a behaviour claim — but it is drift an
operator would size a node on, and it is low by an order of magnitude:
~55 MB, not 4.8 MB.

Second half of the change: #537 measured this ring, and those numbers lived
only in test-harness/load/RESULTS-0.49.7-ring-ab.md. They now sit next to
the knobs someone actually turns, the way the vad row already does it:

• docs/CONFIG.md → sip_ring_size — ~1.9 MB at a realistic
  200-concurrent shape (~2.5 % of that node's whole daemon RSS), ~17 MB with
  the 256-entry pending population saturated at the per-call cap, and the
  ~55 MB design bound together with what it takes to approach it (512
  concurrent calls each having exchanged 64+ messages; real calls carry
  4–8).
• docs/CONFIG.md → sip_ring_max_messages — the per-message cost
  (~1.34 × payload + 285 B, the slope being allocator size-class rounding)
  and the fact that this, not sip_ring_size, is the knob the ceiling scales
  linearly with.
• sip_ring.rs's MAX_LIVE doc comment — the byte figures next to the
  entry-count bound it already documented correctly.

No behaviour change. No code path moves, no default changes, the bounds
themselves are unmoved — docs and one doc comment only. Nothing here needs a
restart or a release.

scripts/check-doc-links.py passes; cargo fmt --all --check clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_011FQwSJ3QXEnPQXGazUXvv5