fix(retrieval): wire AsyncEmbeddingWorker into mcp-server bootstrap (B-MCP-3)

[h2devx]

Que cambia

Wire the AsyncEmbeddingWorker into the mcp-server bootstrap so the
embedding_queue actually drains in production. Cambios son
puramente de wiring + un test de regresion; no se toco el codigo del
worker ni el de las use cases.

Por que

Fixes #2 — B-MCP-3 (critical). El worker existia y estaba testeado al
100% pero ningun bootstrap lo instanciaba. La cola crecia
indefinidamente y mem.recall caia silenciosamente a BM25-only
("fallback_reason: embedder_unavailable"), rompiendo la promesa
central del producto. El dogfood de Phase-9 dejo 64 rows en
embedding_queue con attempts=0 — evidencia empirica del bug.

Tipo de cambio

• fix — bug fix
• test — agrega tests

Checklist

• npm run typecheck EXIT=0
• npm run lint y npm run lint:tests EXIT=0
• npm run validate:modules EXIT=0 (cero violaciones ADR-001)
• npm run build EXIT=0
• npm run test EXIT=0 — 2504 tests passing en 206 archivos (was 2501 in 205)
• Cero any, cero as any, cero // @ts-ignore
• Tests nuevos cubren el cambio
• N/A — wire/protocolo MCP no cambia
• N/A — no introduce ADR
• HANDOFF.md se actualiza al cierre de la fase v0.1.2-beta.1, no en este PR

E2E que validan VALORES

• Los tests nuevos asertan valores reales (no solo shape)

El test tests/integration/L-embedding-worker-drains.test.ts sigue
la metodologia codificada en Phase-9:

1. Estado inicial conocido: embedding_queue=0, embedding_metadata=0.
2. Insertar 1 decision + 1 learning + 1 entity → la cola crece a 3
   filas (target_kind en [decision, entity, learning]).
3. Arrancar el worker, hacer poll hasta que la cola caiga a 0.
4. Asertar valores: queue=0, metadata=3 con dimension=384 y
   embedded_text no vacio, stub embedder invocado >=3 veces.
5. stop() idempotente.

Un segundo caso valida que el worker sobrevive un fallo transitorio
del embedder (failNext=true) sin perder la fila de la cola — guarda
contra el anti-patron "fail-and-forget" que reintroduciria una
variante de B-MCP-3.

Notas para el reviewer

Decisiones de wiring:

• AsyncEmbeddingWorker se construye en buildRetrievalWiring, no
  en el bootstrap entrypoint. La razon: la wiring helper es donde se
  ensamblan los use cases retrieval; el entrypoint solo controla
  ciclos de vida del proceso. Esto deja RetrievalWiring.embeddingWorker
  disponible para tests y cualquier futuro driver (CLI long-running,
  daemon mode).
• Container ahora expone workspaceId publicamente. Antes vivia
  como local en buildContainer. Util para el bootstrap del MCP
  server (no se ejercita en este PR pero queda disponible para
  proximos drivers).
• En el SIGINT/SIGTERM path: worker.stop() se awaita antes de
  shutdown() para que el drain en vuelo no quede a la deriva
  cuando se cierra el handle de SQLite.
• No toco cli-entrypoint.ts. El HANDOFF lo menciona "para
  comandos long-running" pero el CLI hoy son one-shots. Es scope
  creep; lo dejo para una iteracion separada si surge el caso.

Que NO valida este PR:

• Que el path real con FastembedEmbedder funcione end-to-end. Para
  eso hace falta un E2E con descarga real del modelo desde GCS —
  posible pero costoso (30+s en cold cache). El test de integracion
  con stub valida el contrato; el real-fastembed quedaria para una
  validacion de release adicional.