fix(security): cap built-in relay fan-out per poll tick

[cursor]

Security fix

Fixes medium-severity CPU exhaustion DoS in the built-in server relay (issue #129).

Vulnerability

An attacker opens one publisher plus many play connections on the same (app, stream_name) (up to max_connections, default 256). Each publisher frame queued in pending_relay (up to 1024 frames) is fanned out to every matching player on each Server::process_connections() poll tick. Worst case: 1024 × 255 ≈ 261,120 send_frame/chunk-encode calls per poll, monopolizing the single-threaded poll loop.

Distinct from #41 (publisher-side pending_relay memory cap).

Fix

• Add MAX_RELAY_SENDS_PER_POLL = 4096 budget in src/server/mod.rs
• Count players per frame before sending; stop when budget exceeded
• Re-queue unprocessed frames on the publisher via requeue_relay_frame()
• Unit test relay_send_budget_limits_worst_case_player_fan_out

Verification

cargo test — all tests pass.

  

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

[AlexanderWagnerDev]

Applied the security fix to #128 with the conflict resolved against its multitrack relay changes.

Integrated commit: 4965475

The resolved implementation preserves pause, receiveAudio/receiveVideo, metadata, and multitrack player gating while enforcing the per-poll relay-send budget. cargo fmt and cargo test completed before the commit was pushed.