Rate-limit queue is per-instance, not truly global

The comment says "Global rate limiter: serialize all Gemini embedding requests across concurrent callers," but rateLimitQueue is a closure variable created inside createGeminiEmbeddingProvider. Each call to createGeminiEmbeddingProvider produces an independent queue. If the provider is instantiated more than once (e.g., multiple agents each creating their own memory manager), the queues are completely independent and concurrent requests from different instances will not be serialized, which can still exceed the 100 RPM free-tier limit.

To make the queue truly global, move it to module scope:

This is a comment left during a code review.
Path: src/memory/embeddings-gemini.ts
Line: 121-163

Comment:
**Rate-limit queue is per-instance, not truly global**

The comment says "Global rate limiter: serialize all Gemini embedding requests across concurrent callers," but `rateLimitQueue` is a closure variable created inside `createGeminiEmbeddingProvider`. Each call to `createGeminiEmbeddingProvider` produces an independent queue. If the provider is instantiated more than once (e.g., multiple agents each creating their own memory manager), the queues are completely independent and concurrent requests from different instances will not be serialized, which can still exceed the 100 RPM free-tier limit.

To make the queue truly global, move it to module scope:

```suggestion
// module-level, shared across all provider instances
let _globalGeminiRateLimitQueue: Promise<void> = Promise.resolve();
const GEMINI_EMBED_DELAY_MS = 1200;

export async function createGeminiEmbeddingProvider(...) {
  // ...
  const rateLimitedBatch = async (texts: string[]): Promise<number[][]> => {
    return new Promise((resolve, reject) => {
      _globalGeminiRateLimitQueue = _globalGeminiRateLimitQueue.then(async () => {
        // ... same body ...
        await new Promise((r) => setTimeout(r, GEMINI_EMBED_DELAY_MS));
      });
    });
  };
  // ...
}
```

How can I resolve this? If you propose a fix, please make it concise.

Add cancellation path for queued Gemini batch jobs

The new rateLimitQueue serializes every embedBatch call behind the previous callback, but the queued callback awaits the HTTP request without any abort signal. embedBatchWithRetry times out callers after 120s, yet that timeout does not cancel the in-flight queued job, so one stuck Gemini request can block the queue and cause all later batches to time out/retry without ever being sent. This regression only appears after introducing the shared queue and can stall memory index during network hangs or very slow Gemini responses.

Useful? React with 👍 / 👎.

Cancel timed-out Gemini jobs in the shared queue

Fresh evidence: this commit introduces the module-level geminiEmbedRateLimitQueue here, while embedBatchWithRetry still enforces timeout via withTimeout (src/memory/manager-embedding-ops.ts:519) without aborting the underlying HTTP work. If one queued Gemini request hangs, the caller times out after 120s but the queued callback keeps running, so later embedBatch calls remain blocked behind it and can time out before their requests are even sent, causing cascading failures/stalls during memory index under slow or stuck network responses.

Useful? React with 👍 / 👎.

Pass abort signal into queued Gemini batch request

rateLimitedBatch creates an AbortController and a 30s timeout, but the queued request path never passes controller.signal into fetchWithGeminiAuth. In a slow or hung Gemini call, the timeout callback runs without cancelling the HTTP work, so that queue slot can remain occupied until lower-level network timeouts while later batches pile up behind it and hit caller-level timeouts/retries. Threading the signal through fetchWithGeminiAuth and withRemoteHttpResponse is needed for the per-item timeout to actually protect queue progress.

Useful? React with 👍 / 👎.