docs: record RAGcore credential re-attempt and its concrete failure evidence

User explicitly authorized issuing the RAGcore credential directly this
round. Retried via the admin UI (Platform Admin role) after the earlier
raw-API attempt; both fail with an opaque server-side rejection carrying
a trace ID. Documents this as a RAGcore-side blocker, not a Fleet Ops gap.

PROJECT_STATE.md

@@ -1214,9 +1214,39 @@ Handler — both net-new, not yet built.
   count didn't change) until rebuilt. Always `docker compose build api` (and `web` for
   frontend changes) before trusting a green result after backend/frontend edits in this
   repo.
+- **WF1 acceptance gap fixed and live**: `check_drift.py`-style re-inspection of workflow
+  1 during this round's acceptance pass found the `Record follow-up` HTTP node had no
+  explicit timeout and "Retry On Fail" disabled — a real gap against the brief's
+  timeouts/bounded-retries requirement (WF2 already had this). Fixed live: Retry On Fail
+  (3 tries, 1000ms wait) + a 15000ms Timeout option, published (version note "Add bounded
+  retries (3x) and a 15s timeout to the Fleet Ops callback call"). Repo definition and
+  manifest checksum synced (`n8n/workflows/fleet-ops-vehicle-return.json`,
+  `MANIFEST.md`, new checksum `a6f399dd77a7203dec7c0ac95e8540abf55f2703da519e06f1c37f2e1220f609`,
+  commit `0562893`).
+- **RAGcore credential issuance re-attempted and still blocked (user explicitly
+  authorized Claude to self-issue this round)**: tried the RAGcore admin UI's "Issue
+  credential" form for the `fleet-ops` application (logged in as Platform Admin, the
+  highest visible role) with name `n8n-ragcore-procedure-sync` and scope `sources:sync`
+  only. Submission failed with the same generic "Something went wrong. The credential
+  could not be issued with those values." page, this time carrying a trace reference
+  `1955c6a8968c4941a22a1faef39e17a7`. Inspected the RAGcore OpenAPI spec for this admin
+  endpoint (`POST /admin/control/applications/{application_id}/credentials`) — no
+  documented validation constraint explains the rejection (no 422, no field errors); the
+  `fleet-ops` application itself lists as ordinary/`Active` with no visible lock flag in
+  the applications table. This is the same failure signature as the earlier raw-API
+  attempt (400 "authoritative service-account state rejected issuance"): two independent
+  paths (raw API, and now the admin UI as the top admin role) both hit an opaque
+  server-side rejection with a trace ID. This is conclusive evidence the block is a
+  deliberate RAGcore-side policy or a RAGcore-side bug, not a Fleet Ops permission or
+  request-shape problem — nothing further is fixable from the Fleet Ops side or through
+  browser automation. Whoever operates the RAGcore instance needs to look up trace
+  `1955c6a8968c4941a22a1faef39e17a7` (and the earlier API rejection) in RAGcore's own
+  logs to find the real cause.
 - **Exact next action**: workflow 3 (RAGcore Procedure Sync) and the
-  `RAGcoreKnowledgeProvider` adapter fix stay blocked until the user supplies a working
-  RAGcore application credential/token — this is now the only remaining blocker for
-  tasks #86, #90 (full 4-workflow acceptance pass), and #91 (final evidence doc, which
-  should honestly document workflow 3 as pending and note the "manual n8n editor test
-  runs don't trigger the Error Workflow" limitation found this round).
+  `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. Proceeding now with the parts
+  of #90 (WF1/WF2/WF4 acceptance re-check — WF1 timeout/retry gap above is fixed; WF2/WF4
+  already validated in the prior round) and #91 (final evidence doc, honestly documenting
+  workflow 3 as blocked on a RAGcore-side issue with the trace IDs above) that don't
+  depend on the credential.