fix(sse): propagate AbortSignal to pre-fetch semaphore and rate-limit awaits

[wucm667]

Fixes #1766

Problem

When a combo target takes too long (e.g., deepseek-v4-pro on opencode-go), the request-level deadline fires and calls abortController.abort() on the stream controller — but the abort signal never reaches pending awaits in acquireAccountSemaphore() or withRateLimit().

These awaits sit between createStreamController() and executor.execute(), so the abort can't terminate them. The result: requests that should abort at the 600s deadline hang indefinitely (observed 11m 49s hang).

Fix

Propagate streamController.signal to both pre-fetch awaits:

1. accountSemaphore.ts: Added optional signal parameter to AcquireAccountSemaphoreOptions. When provided and the signal is already aborted, the function rejects immediately. While queued, an abort listener removes the item from the queue and rejects with an AbortError, cleaning up both the listener and the timeout timer.

2. rateLimitManager.ts: Added optional signal parameter to withRateLimit(). When provided, it races the Bottleneck schedule() call against an abort promise that rejects with AbortError when the signal fires.

3. chatCore.ts: Passed streamController.signal to both acquireAccountSemaphore() and withRateLimit() calls in the request execution path.

Changes

File	Change
open-sse/services/accountSemaphore.ts	Add signal to options interface; reject on abort while queued; cleanup listeners
open-sse/services/rateLimitManager.ts	Add signal parameter; race schedule against abort promise
open-sse/handlers/chatCore.ts	Pass streamController.signal to both functions

[gemini-code-assist]

Code Review

This pull request introduces AbortSignal support to the account semaphore and rate limiting services, allowing for the cancellation of pending requests. The changes propagate the signal from the chat handler down to the semaphore and rate limiter implementations. Feedback was provided regarding potential memory leaks in rateLimitManager.ts due to unremoved event listeners and race conditions in both services where signals might abort between the initial check and listener attachment.

[wucm667]

Thanks for the review! Addressed both comments:

rateLimitManager.ts — Fixed the race condition by checking `signal.aborted` inside the Promise constructor before attaching the listener, and added a `finally` block to remove the listener after `Promise.race` completes (prevents accumulation on long-lived signals).

accountSemaphore.ts — Added the pre-attach `signal.aborted` check before `addEventListener`, closing the race window between the initial check and listener attachment.