fix: Warm the retrieval embedder inside ZeroGPU's import window too

The import-scope fix worked for the language model -- the Space starts, ZeroGPU
packs 17.6G of tensors, /api/status reports ready with all 80,370 chunks -- but
the embedder is a second model and was still lazy. It loads on the first query,
which is a request, outside the import window, so it hit the identical
_cuda_init wall and every answer came back with "[agent] retrieval failed":
the demo would have run with no retrieval and no citations, quietly.

_build_agent_at_import now embeds one throwaway string, which is what actually
triggers get_embedder()'s load, so both models land on the GPU during import.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -201,7 +201,10 @@ and attaches real hardware only inside a `@spaces.GPU` call; only CUDA operation
 window are intercepted. `app.py` normally builds the model in FastAPI's `lifespan`, on a
 `ThreadPoolExecutor` worker — after import, on another thread — and `.to("cuda")` there reaches real
 CUDA init and raises. `app_space.py::_build_agent_at_import` builds the agent during import and
-assigns `app._agent`, so `lifespan`'s `get_agent()` is a no-op. `device_map` fails independently, by
+assigns `app._agent`, so `lifespan`'s `get_agent()` is a no-op. **The retrieval embedder is a second
+model with the same problem** — it loads lazily on the first query, which is a request, outside the
+window — so the same function embeds one throwaway string to force it onto the GPU during import.
+Without that, the Space starts fine and every answer carries `[agent] retrieval failed`. `device_map` fails independently, by
 routing transformers through `caching_allocator_warmup` and its direct
 `torch.empty(..., device="cuda")`; bitsandbytes requires `device_map`, so **4-bit quantisation is
 unavailable**, which is what forces a model small enough to carry in bf16: `Qwen/Qwen3-8B`, ~16GB

app_space.py

@@ -76,10 +76,18 @@ def _build_agent_at_import() -> None:
     """
     from controlai_agent.agent import ControlAgent
     from controlai_agent.engine_torch import TorchEngine
+    from controlai_rag.embeddings import get_embedder
 
     print("[space] building agent at import scope (ZeroGPU CUDA window)")
     app_module._agent = ControlAgent(engine=TorchEngine())
-    print("[space] agent ready")
+
+    # The retrieval embedder is a second model, and it loads lazily on first
+    # query -- which is a request, outside the import window, so it hit exactly
+    # the same _cuda_init wall and every answer came back with
+    # "[agent] retrieval failed". Force it onto the GPU here too. Embedding one
+    # throwaway string is what actually triggers the load.
+    get_embedder().encode_query("warmup")
+    print("[space] agent and embedder ready")
 
 
 _fetch_index()          # the agent prewarms retrieval, so the index must precede it