docs: record live /v1/answers verification and a retrieval finding

Issued a fresh scoped credential via the RAGcore admin UI (separate,
working OIDC session, unaffected by the n8n auth problem) and made a
real authenticated /v1/answers call. Got a clean 200 with a real
answer_id/retrieval_run_id, not degraded -- but not_answerable, 0
citations.

Confirmed this isn't a regression: the same query through RAGcore's
own pre-existing Query Lab tool (untouched this session) returns the
identical result down to zero dense/sparse candidates at the raw
retrieval stage. Ruled out the obvious causes via direct Qdrant/
Postgres checks -- workspace_id, space_id, status, and embedding
digest all correctly match real indexed content. Root cause not yet
found; flagged as a follow-up rather than pursued further to avoid
scope creep on what was a deployment-verification task.

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

PROJECT_STATE.md

@@ -1541,19 +1541,36 @@ Handler — both net-new, not yet built.
   - **Live-verified the fix itself**: `POST /v1/search` now returns `401
     AUTHENTICATION_REQUIRED` for an unauthenticated call, not the old permanent `503
     SEARCH_UNAVAILABLE` — proof the endpoint reaches real request handling instead of
-    hitting an absent application state, which is exactly the bug this closes. Did **not**
-    complete a full authenticated `/v1/answers` call with a real grounded-answer response
-    — the previously-issued "Fleet Ops Knowledge Assistant (production)" credential's raw
-    token was never persisted anywhere retrievable (tokens are shown once at issuance,
-    stored hashed thereafter) and issuing a fresh one requires the RAGcore admin control
-    API's own principal/session, not attempted this round to avoid another live-login
-    detour after the n8n incident above. Next session (or the user) should issue a fresh
-    scoped credential via the RAGcore admin UI and do one real `/v1/answers` call before
-    flipping `KNOWLEDGE_PROVIDER=ragcore`.
+    hitting an absent application state, which is exactly the bug this closes.
+  - **Issued a fresh scoped credential** (`answer` scope, application `Fleet Ops`, via the
+    RAGcore admin UI at `rag.itworx.tech` — a separate, working OIDC session, unaffected by
+    the n8n auth problem above) and made a real authenticated `POST /v1/answers` call
+    against the `Fleet Ops Procedures` knowledge space (`f4c91e49-5cf9-48ba-b3d6-e0e9854ebccc`).
+    Got a clean `200`, a real `answer_id`/`retrieval_run_id`, `degraded: false` — but
+    `answerability: not_answerable`, 0 citations, for two different real questions matching
+    real seeded document titles.
+  - **Confirmed this is not a regression from this change**: the same query against the
+    same space through RAGcore's own pre-existing, already-proven Query Lab tool (which
+    uses `PipelineQueryLabExecutor`, code this session never touched) returns the identical
+    `NOT_ANSWERABLE` / 0 evidence / not degraded result — down to `Dense candidates (0)` and
+    `Sparse candidates (0)` at the raw retrieval stage, before fusion or rerank ever runs.
+    Whatever is causing zero matches lives in shared retrieval infrastructure or the data
+    itself, not in the new production executors.
+  - **Ruled out the obvious causes via direct Qdrant/Postgres checks** (not yet root-caused
+    further — flagging as a separate follow-up, not blocking this task): the space
+    genuinely has 83 published, correctly-scoped points in `rag_dense_nomic-embed-text_v1`
+    (right `workspace_id`, right `space_id`, `status: published`, real Dutch-language
+    procedure text); the points' `embedding_model_digest` exactly matches the currently
+    active embedding profile's digest (no stale-embedding mismatch); the collection alias
+    (`rag_dense_nomic-embed-text_active`) correctly resolves to that same collection. One
+    oddity noted in passing, unrelated to retrieval: at least one sampled chunk has
+    `language: "en"` in its payload despite the actual text being Dutch — worth a look if
+    language-filtered queries matter for the demo.
   - **Decision on `KNOWLEDGE_PROVIDER=ragcore` in Fleet Ops**: still deliberately `demo`.
-    RAGcore's application is now deployed and structurally verified, but a full
-    authenticated grounded-answer call hasn't been done yet (see above) — flip only after
-    that final live check.
+    The application is deployed, correctly wired, and behaves identically to RAGcore's own
+    trusted reference implementation — but real questions against real seeded content
+    aren't returning grounded answers yet for a reason that traces to shared
+    retrieval/data, not to this wiring. Flip only after that's root-caused.
 
 - **n8n workflow 3 (task #86) — incident, recovered; final 2 nodes still blocked on a
   live n8n auth problem, not a code problem.** Returning to finish the "Summarize sync
@@ -1591,10 +1608,13 @@ Handler — both net-new, not yet built.
     blocked before any node configuration happened. The design itself (mirroring WF2/WF4's
     existing report-result pattern) is unchanged from earlier planning.
 
-- **Exact next action**: (1) RAGcore search/answer wiring (`a2905cc`) is now deployed and
-  structurally verified — issue a fresh scoped credential via the RAGcore admin UI, do one
-  real authenticated `/v1/answers` call, and only then reconsider flipping
-  `KNOWLEDGE_PROVIDER=ragcore` in Fleet Ops. (2) task #86's remaining n8n pieces (Summarize
+- **Exact next action**: (1) RAGcore search/answer wiring (`a2905cc`) is deployed and
+  proven correctly wired (matches Query Lab's trusted behavior exactly) — the open item is
+  now root-causing why `Fleet Ops Procedures` returns zero dense/sparse candidates for
+  real questions despite having genuinely matching, correctly-scoped, correctly-embedded
+  indexed content (see evidence above); this is retrieval/data, not application wiring.
+  Only flip `KNOWLEDGE_PROVIDER=ragcore` once that's fixed and a real grounded answer comes
+  back. (2) task #86's remaining n8n pieces (Summarize
   + report-result node, publish) need the live n8n instance's save/auth problem fixed
   first — this looks like an n8n-instance-side issue (session/auth backend rejecting
   mutating requests moments after a successful login), not something fixable from the