fix(proxy): stop spending quota on h2 requests the client abandoned

[ak2k]

Builds on #180 and the activity-entry PR. Review those first; the diff here is the last commit only.

A cancelled h2 request keeps consuming quota. With four accounts, if the first account answers a cancelled request with a quota rejection, the retry ladder tries the other three as well, and each retry is a real upstream call billed to that account's weekly bucket.

before: a cancelled h2 request spent 4 of 4 accounts
after:  it spends 1

Why

The retry guards check res.destroyed. Http2ServerResponse has no destroyed property, so on the MITM path the check reads undefined and never trips. The h2 equivalent is res.stream.destroyed.

The MITM path carries most traffic: HTTPS_PROXY pointed at teamclaude is how a claude instance connects, and the terminating server negotiates h2 with any client that offers it.

The fix

A clientGone(res) helper covers both transports: res.destroyed on h1, res.stream?.destroyed on h2. All of the res.destroyed reads move to it, including the retry-ladder rungs, the concurrency slot's abort probe, the late 429 and 502 answers, and the recovery's status choice.

A stranded handler on the streaming path

The inert check has a second consequence. res.write to a cancelled stream returns false, which sends streamResponse into its backpressure wait:

await new Promise(resolve => {
  const done = () => { res.off('drain', done); res.off('close', done); resolve(); };
  res.once('drain', done);
  res.once('close', done);
});

On a cancelled h2 stream, close has already fired before this listener is registered, and drain never fires on a closed stream, so the promise never settles. The check that should have exited the loop before the write is the inert one, so the handler never returns. Cancelling an h2 SSE stream after its first chunk, without the fix:

sawChunk=true  started=1  ended=0  returned=false

The activity entry stays open, undoing the accounting PR below this one on the streaming path, and the stranded handler sits on the event loop for the life of the process. With the fix, the same probe reports started=1 ended=1 returned=true.

Test design

The guards are mutually redundant: reverting any single call site outside the streaming path changes nothing, because another site catches the same cancellation. So the tests measure accounts spent and whether the handler returns, not which guards ran.

Reverting the h2 arm of clientGone itself restores both defects at once:

h2 arm dropped from the helper -> spent 4 of 4 accounts, and the handler strands again

Site-level results, for the record:

only the admit() abort probe converted -> spends 1 of 4
only the quota-429 rung converted      -> spends 1 of 4
both reverted, the rest converted      -> spends 4 of 4

The sites a quota-429 ladder does not exercise are converted for uniformity; the ladder test does not reach them. On the streaming path, reverting the check before the write turns the strand test red. The check after the backpressure wait is a backstop for a cancel that lands during the wait itself; that race cannot be driven reliably in a test, so it is noted here instead.

Tests

Two, in test/mitm-integration.test.js. Both drive a real CONNECT tunnel with h2 negotiated over ALPN and a real cancellation (NGHTTP2_CANCEL), and both verify the setup worked before asserting the result.

The ladder test uses four accounts whose upstream answers each with a quota rejection, confirms the upstream was actually reached, and waits for the ladder to stop growing rather than sleeping a fixed span, since a fixed sleep can read the count before the remaining rungs run.

The strand test cancels an SSE stream after its first chunk and asserts the handler returned, using the closed activity entry as the signal. It runs the proxy in a child process: a stranded handler would keep the test runner itself from exiting, so the parent enforces the timeout.

$ node --test --test-timeout=120000
ℹ tests 540
ℹ pass 540
ℹ fail 0

538 before, 540 after. npx eslint . clean.

Compatibility

h1 is unchanged: clientGone reads the same res.destroyed as before, and res.stream?.destroyed is undefined there. On h2, a live request sees no difference, since its stream is not destroyed; a cancelled one stops instead of continuing to retry.

[ak2k]

Rebased onto #181's current head; the two branches had diverged by five comment-wording lines, which made the stack conflict with itself. No code change.