Follow-up from #378 / #379 (Copilot review pass 2).

The current `--cors-proxy-timeout-ms` deadline applies to the headers-received phase only. Once Fastify has sent the 200 status to the client we can't change it to a 504, and the obvious "destroy the upstream Node stream mid-pipe" fix doesn't reliably terminate the response (the pipe doesn't propagate cleanly and curl observed the connection hanging until upstream's own deadline — ~75 s for httpbin's drip endpoint).

Failure mode

• Client opens `/proxy?url=https://upstream/slow-stream\`
• Upstream sends headers fast, body slowly
• Pod streams the partial response while the connection stays open
• No JSS-side cap on body duration

Acceptance

• `--cors-proxy-timeout-ms` (or a new `--cors-proxy-idle-timeout-ms`?) applies to the body phase too: connection closes with a truncated body if the upstream goes idle past the deadline
• No `ERR_HTTP_HEADERS_SENT` on the JSS process
• Test: serve a deliberately-slow upstream from another local Fastify instance, request through the proxy, assert the connection terminates within the deadline

Possible shapes

1. Idle timer reset on each chunk — set a short timer per chunk; if no chunk arrives before it fires, abort the underlying `AbortController` and let the destroy propagate
2. Hard deadline that overrides headers-mode timeout — separate `--cors-proxy-overall-timeout-ms` for the full transfer
3. Just close the socket without trying to send a graceful end (less elegant but reliable)

(1) is probably the right shape — matches what most reverse proxies do.

Refs

• Feature: --cors-proxy — WAC-gated CORS proxy for arbitrary upstreams #378 — the feature
• cors-proxy: Phase 1 — WAC-gated proxy for browser apps (#378) #379 — the PR with the deferred-from-Phase-1 limitation
• Copilot review thread on cors-proxy: Phase 1 — WAC-gated proxy for browser apps (#378) #379 line 235