fix(quota-share): give each in-flight request its own lease

[abhisheksharma2411]

Summary

The quota-share in-flight counter is what P2C reads to pick the less-loaded connection, and its leak bound did not hold.

A slot carried one expiry per connection, and incrementInflight() refreshed it on every increment. So a request that aborted before its release callback ran kept its count alive for as long as the connection kept taking traffic — the leak was unbounded precisely when the connection was busy, which is when P2C's view of load matters most. The module docstring promises the opposite:

the counter can never leak forever, even without touching the generic dispatch

Reproduction

Driven through the injectable clock, so it is deterministic. One orphaned increment, then a request every 60s that increments and releases correctly:

t=0     incrementInflight("conn-X")            // request aborts, never releases
t=60s   increment + decrement                   // normal traffic
t=120s  increment + decrement
...
t=600s  getInflight("conn-X") -> 1

Ten minutes on — five times the 120s DEFAULT_LEASE_MS — the orphan still counts. Every later increment pushed the shared expiresAtMs forward, so it never aged out.

Fix

Each request now carries its own expiry and the count is the number of live leases, so an orphan ages out on its own schedule regardless of what its neighbours do.

Retiring on release needs a rule, because a release does not say which request settled:

1. If any lease has already expired, retire the newest of those. A request that outlived its own lease is by definition the longest-running one, so an expired lease is the best match for the caller — and consuming it leaves live neighbours alone. Retiring a live lease instead would decrement twice for a single settled request: once when the expiry lapsed, once again now.
2. Otherwise retire the newest live lease — never the oldest, or a normal request's release would retire an orphan's lease and leave its own newer one behind, and the orphan would never age out.

Rule 1 exists because my first attempt got this wrong, and I would rather show that than hide it. Retiring expired leases and then popping a live one made this case report 1 where the previous code correctly reported 2:

A at t=0 (lease -> 120s), B at t=100s (-> 220s), C at t=110s (-> 230s)
A releases at t=130s, B and C still genuinely in flight

before this PR : 2   correct
first attempt  : 1   regression
this PR        : 2   correct

Bounded at 4096 leases per connection; past that the oldest is dropped, which can only under-count an already-saturated connection — the fail-open direction this module takes everywhere else (getInflight returns 0 for anything unknown).

Scope, and what I am not claiming

I originally thought a second bug was here — that decrementInflight deleting the whole entry on an expired slot would zero out live neighbours. It does not, in practice. Because the shared expiry was refreshed by every increment, it could only lapse after a full lease with no traffic, by which point there are no live neighbours to lose. I checked before writing it up rather than after. The only defect fixed here is the leak.

Tests

Three added to tests/unit/quota-share-strategy.test.ts. Two fail against the current implementation, verified by swapping the base file in and confirming the swap took effect before running:

without the fix:  34 tests, 32 pass, 2 fail
  ✖ an orphaned lease expires even while the connection keeps taking traffic
  ✖ expired leases are retired without an explicit decrement, per request

The third pins neighbour-preservation, which already held and now holds by construction — flagging that so it is not miscounted as a third regression caught.

Full runs on this base: quota-share-strategy 34/34, tests/unit/combo/* 162/162, tests/unit/*quota* 1424 green, tsc -p tsconfig.typecheck-core.json clean.

Notes

• Cut from release/v3.8.51 (the current default).
• No behaviour change for the ordinary path: increment, then release while the lease is live, still takes the count straight back down.
• Found while reviewing fix(quota-share): release the winner's reserved in-flight slot (#11371) #11408, which fixes the missing release call. This is a separate defect in the counter itself, and the two compose: with fix(quota-share): release the winner's reserved in-flight slot (#11371) #11408 landing, the ordinary path releases correctly, and this makes the abort path actually bounded rather than nominally bounded.