fix: prevent streaming transfers from hanging on degraded connections

[sanity]

Problem

GET requests for large contracts (~1MB, e.g. the River UI container) consistently fail because streaming transfers die mid-transfer. The responding peer starts sending fragments but they stop arriving, causing stream assembly timeouts (30s).

User impact: River UI cannot load. Users see "GET request timed out after 30s". Affects users with otherwise healthy nodes (16+ ring peers). Multiple diagnostic reports confirm the pattern (E7NJG5, 23TN9A).

Root cause: The cwnd_wait loop in send_stream and pipe_stream has no timeout. When the FixedRateController's loss_pause activates (on packet loss/RTO), it caps cwnd at flightsize, blocking all new data until an ACK clears it. This is correct for transient loss (ACKs arrive in 1-2s), but when the outbound connection degrades (consecutive retransmission failures with exponential RTO backoff: 1s→2s→4s→8s→16s = 31s), the sender stalls for >30s and the receiver's STREAM_INACTIVITY_TIMEOUT fires with no diagnostic from the sender.

Large transfers (737 fragments for ~1MB) are disproportionately affected because more fragments = more chances for loss events and longer total transfer time.

Approach

Add CWND_WAIT_TIMEOUT (20s) to both send_stream and pipe_stream. Set below the 30s STREAM_INACTIVITY_TIMEOUT so the sender fails first with a clear diagnostic message ("cwnd wait timed out — outbound connection likely dead"), rather than the receiver timing out silently.

The fix preserves the existing loss_pause behavior (complete block until ACK clears it) for transient loss recovery, while adding a safety net for dead connections.

Testing

• All 2068 existing tests pass (0 failures)
• Added test_send_stream_cwnd_wait_timeout: verifies send_stream returns ConnectionClosed when cwnd wait exceeds timeout, and that completion_tx fires on timeout
• Fixed telemetry bytes_sent overestimate (now capped at bytes_to_send)

Closes #3608

[AI-assisted - Claude]

[github-actions]

🔍 Rule Review: cwnd timeout for degraded connections

Rules checked: transport.md, code-style.md, testing.md, git-workflow.md
Files reviewed: 2 (fixed_rate/controller.rs, peer_connection/outbound_stream.rs)

Critical

None.

Warnings

None.

Info

• outbound_stream.rs:42–46 — CWND_WAIT_TIMEOUT is hardcoded at 20s and documented as being "below the receiver's STREAM_INACTIVITY_TIMEOUT (30s)." If STREAM_INACTIVITY_TIMEOUT is itself a named constant, the code-style rule recommends deriving from it rather than keeping the relationship in a comment alone. Not a blocker, but fragile if the receiver timeout ever changes. (rule: code-style.md — numeric thresholds)

• outbound_stream.rs:1101 (test) — The test uses RealTime::new() inside crates/core/ with #[tokio::test(start_paused = true)]. The comment explains that VirtualTime requires manual advance() calls that don't interleave with the cwnd loop's sleep iterations. This is a reasonable exception, but it ties test correctness to RealTime being backed by tokio::time (not std::time::Instant). Worth confirming RealTime::now() delegates to tokio::time::Instant::now() so the paused-clock auto-advance actually works — if it uses std::time, the 20s timeout would never fire and the test would hang. (rule: testing.md — TimeSource / determinism)

---

No Critical or Warning findings — merge is not blocked by this check.

---

Automated review against .claude/rules/. Critical and Warning findings block merge — check boxes or post /ack to acknowledge.

[github-actions]

⚠️ Extended Benchmark Regressions Detected

Some extended benchmarks show performance regressions.

Note: Extended benchmarks include high-latency and packet-loss scenarios
which have higher variance than standard CI benchmarks.

View full results

View full benchmark summary

[github-actions]

⚠️ Extended Benchmark Regressions Detected

Some extended benchmarks show performance regressions.

Note: Extended benchmarks include high-latency and packet-loss scenarios
which have higher variance than standard CI benchmarks.

View full results

View full benchmark summary

[iduartgomez]

address #3608 (comment)