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.