docs: record root cause and fix for the RAGcore credential-issuance bug

With explicit owner approval, traced the persistent credential-issuance
rejection to a cross-transaction race in RAGcore's own dependency
injection (two independent DB transactions per request instead of one
shared transaction), fixed and deployed it in RAGcore, and verified a
working "RAGcore Sync Token" n8n credential now exists. Unblocks
workflow 3 and the RAGcoreKnowledgeProvider adapter rewrite.

PROJECT_STATE.md

@@ -1260,12 +1260,36 @@ Handler — both net-new, not yet built.
   failed error-report is visible in n8n's own execution history even without retries) —
   not blocking, but worth finishing once someone re-authenticates the n8n browser
   session.
-- **Exact next action**: workflow 3 (RAGcore Procedure Sync) and the
-  `RAGcoreKnowledgeProvider` adapter fix stay blocked on RAGcore's own credential-issuance
-  rejection (not a Fleet Ops-side gap) — this is the only remaining blocker for task #86
-  and, transitively, the RAGcore-sync portion of #90/#91. WF1 and WF2's
-  timeouts/bounded-retries gaps are now fixed and live; WF4's matching gap on its own
-  outbound call is identified but not yet fixed (n8n browser session expired mid-edit —
-  needs re-authentication to finish, see above). Writing the final evidence doc (#91) next,
-  honestly documenting workflow 3 as blocked on RAGcore and the WF4 retry hardening as a
-  minor open follow-up.
+- **RAGcore credential-issuance blocker root-caused and fixed (in RAGcore itself, with
+  explicit owner approval)**: with read access to the sibling `C:\Projects\RAGcore`
+  checkout, traced "authoritative service-account state rejected issuance" to a genuine
+  cross-transaction race in RAGcore's own dependency injection
+  (`src/ragcore/api/v1/control/dependencies.py`). `get_control_application` and
+  `get_credential_service` each independently opened their own `factory.begin()`
+  database transaction. Issuing a credential for a brand-new service account does, in one
+  request: (1) INSERT the service account via the first dependency's transaction, then
+  (2) immediately re-read it via the second dependency's *separate, uncommitted* transaction
+  — invisible under READ COMMITTED isolation until the first transaction commits, which
+  only happens after the endpoint returns. This made every fresh-service-account credential
+  issuance fail, 100% of the time, via both the raw API and the admin UI (explaining the
+  identical failure signature on both paths). RAGcore's own tests never caught this because
+  they override these dependencies with an in-memory fake that ignores transaction boundaries
+  entirely. Fixed by introducing one shared, cached `get_control_session` dependency that
+  both providers now depend on via `Depends(...)`, so they share one transaction per request.
+  Verified: RAGcore's own test suite (64 tests across `tests/web`, `tests/contract/api/control`,
+  `tests/security/identity`, `tests/unit/domain/control`, `tests/api`) passes, ruff and mypy
+  clean. Deployed to the live RAGcore instance (also on the Unraid host, `ragcore-app-1` on
+  port 1237 — a shared service also used by other ITWorx projects) via `docker compose build`
+  + `up -d`, with explicit owner approval before both the code change and the deploy.
+  Confirmed fixed live: issuing a credential for `fleet-ops` (name
+  `n8n-ragcore-procedure-sync`, scope `sources:sync`) now succeeds (prefix `rc_sa_6fc51e`).
+  The plaintext token was never printed/logged — copied via RAGcore's own "Copy" button and
+  pasted directly into a new n8n Header Auth credential named **"RAGcore Sync Token"**
+  (header `Authorization: Bearer <token>`), ready for workflow 3.
+- **Exact next action**: task #86 (build workflow 3, RAGcore Procedure Sync) and the
+  `RAGcoreKnowledgeProvider` adapter rewrite (to the real inspected contract — `/health/live`,
+  `/health/ready`, `POST /v1/uploads`, `POST /v1/search`/`/v1/context`/`/v1/answers`) are now
+  unblocked — the "RAGcore Sync Token" n8n credential exists and works. WF4's own
+  timeout/retry gap is still open pending n8n browser re-authentication (minor, non-blocking,
+  see above). Both #90 and #91 should be revisited once workflow 3 is actually built, since
+  they currently document it as blocked.