fix(router): make load accounting cancellation-safe

[bvolpato]

Purpose

Cache-aware routing increments worker load before each typed request. Manual cleanup can miss cancellation paths, double-decrement some failures, and release streaming load before response body lifetime ends. Health checkers currently mask drift by resetting counters periodically, which can also erase valid load from long-running requests.

Use scoped load guards for regular and prefill/decode routing. Each request or phase now releases its counter exactly once when scope ends, including errors, retries, task cancellation, stream completion, and client disconnect. Remove periodic resets because counters now follow request lifetimes.

Endpoint registration remains separate in #199.

Test Plan

• Cancel a regular typed request while its load guard is active and verify load returns to zero.
• Drop a regular streaming response after headers while the backend body stalls and verify load returns to zero.
• Cancel a prefill/decode phase while its guard is active and verify load returns to zero.
• Verify decode load remains active after headers until the response body is dropped.
• Verify decode EOF and body errors release load exactly once.
• Preserve concurrent pre-existing worker load when one request guard exits.
• Run the full Rust lint and test suite.

Test Result

• cargo fmt --all -- --check: passed.
• cargo clippy --all-targets --all-features -- -A clippy::result_unit_err -A clippy::chunks_exact_to_as_chunks -A clippy::result_large_err -A clippy::for_kv_map -D warnings: passed. The four allowed lints are unrelated Rust 1.98 warnings in existing code.
• cargo test --all-features: passed, including 491 library tests, every integration suite, and 4 documentation tests; 1 documentation test was ignored.
• Focused response-lifetime regressions for regular and prefill/decode routing: passed.
• git diff --check: passed.

---

Essential Elements of an Effective PR Description Checklist

• Purpose documented.
• Test plan documented.
• Test results documented.

[bvolpato]

Consolidation note: #215, #216, and #176 overlap the load-accounting work here. This PR's current head still needs two streaming boundaries addressed: the regular forwarding task must observe receiver closure while awaiting an upstream chunk, and PD decode load must survive response headers until the body finishes or is dropped.

#215 has the receiver-closure handling, #216 removes health-driven resets and adds request-path cancellation coverage, and #176 tracks the PD response body lifetime. Combining these pieces with a headers-then-stall regression would be preferable to another competing load-accounting implementation. Load-counter cleanup alone does not establish backend generation abort or GPU drain.

[hsliuustc0106]

Reviewed at 1a79e2cf. Strong correctness PR — no code findings:

• RequestLoadGuard RAII replaces every manual increment/decrement pair, which also fixes the stale-Arc bug where a re-registered worker's fresh counter got decremented by an in-flight request's cleanup.
• The streaming forward task now selects on tx.closed(), so load is released when the client disconnects even if the upstream stalls — the old code only noticed via send-failure on the next chunk.
• Both periodic load-reset "drift masks" are removed, including the registry's unconditional reset, which was periodically zeroing busy workers' counters — itself a live accounting bug.
• The tests (concurrent load, task abort, stalled-upstream + client drop) are exactly the right ones.

One rebase note (P3): the branch predates the #283 merge; main's send_typed_request now has the gRPC branch with LoadTrackedBody/GrpcStreamTask body-lifetime tracking. After rebasing, the two mechanisms need reconciling so gRPC streaming neither double-holds nor leaks load. CI on this branch is green only against the pre-merge base.

---

From an automated daily review pass over new/updated PRs (head SHA frozen at 1a79e2cf).