docs: record n8n workflow-3 wipe/recovery and the live auth blocker

The live "Fleet Ops -- RAGcore Procedure Sync" workflow's canvas was
found at zero nodes -- the earlier session's abandoned direct n8n
REST API attempt had gone far enough to wipe it before hitting its
401. Recovered via n8n's own Version History "Restore version"
action back to the last good 4-node save; verified via DOM node
count before and after.

Adding the two remaining nodes then hit the same failure mode: n8n's
own first-party autosave reported "Unauthorized" moments after a
fresh, successful interactive sign-in. Stopped deliberately rather
than retrying against a live instance that already caused one data
loss incident this session -- this looks like an n8n-side session/auth
problem, not something fixable from browser automation.

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

PROJECT_STATE.md

@@ -1539,12 +1539,51 @@ Handler — both net-new, not yet built.
     deployed to the live RAGcore instance and live-verified end-to-end; revisit once that
     deploy happens.
 
+- **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
+  result" + report-to-Fleet-Ops nodes found the live "Fleet Ops — RAGcore Procedure Sync"
+  workflow's canvas at **zero nodes** — the earlier session's abandoned attempt to call
+  n8n's REST API directly (the "unexplained 401" noted above) had gone through far enough
+  to wipe the live workflow before the 401 stopped it, leaving an empty, unsaved "Current
+  changes" draft on top of the last good save.
+  - **Recovered**: n8n's own Version History (`/workflow/.../history`) still had the last
+    good save, version `260b38b5` (Aug 4, 21:08), with all 4 real nodes intact (Schedule
+    Trigger -> List procedures -> Prepare uploads -> Upload to RAGcore) plus the build
+    sticky note. Used the history panel's own **Restore version** action (not a manual
+    rebuild) to bring the live workflow back to that exact state. Confirmed via the page's
+    DOM (`[data-test-id="canvas-node"]` count) both before (0) and after (4) — the canvas
+    itself render fully off-screen (nodes positioned at negative Y coordinates, a separate
+    display-only vue-flow pan bug worked around by directly setting the transform pane's
+    CSS transform; harmless, doesn't touch saved data).
+  - **Then blocked again attempting the 2 new nodes**: adding a Code node via the UI's own
+    "What happens next?" panel (a real, first-party n8n interaction, not the REST API)
+    immediately surfaced n8n's own autosave toast: **"Problem saving workflow — Autosave
+    failed: Unauthorized."** A full sign-out/sign-in cycle right before this (fresh
+    credentials, fresh page load) did not fix it — immediately after a successful
+    interactive "Sign in", `fetch('/rest/workflows/...')` from that same authenticated tab
+    still returned 401. This is not the ordinary "your session expired, log in again"
+    friction seen earlier in the session; it's the live n8n instance's own save path
+    rejecting a request made moments after a successful login, which is exactly the
+    failure mode that caused the wipe above. Continuing to add nodes under this condition
+    risks losing work again with no guarantee the next failure is as recoverable, so this
+    was stopped deliberately rather than retried. The workflow was left in its safely
+    restored, 4-node, unpublished state — verified via the DOM node count immediately
+    before closing the session — nothing was added or changed beyond the restore.
+  - **Not a code/workflow-design problem**: the 2 remaining nodes (a Code node
+    summarizing the sync result, and an HTTP node reporting to Fleet Ops's already-live
+    `POST /api/v1/integrations/n8n/procedures-sync-result`) were never built — this
+    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) decide on deploying the RAGcore search/answer wiring
   (`a2905cc`) to the live RAGcore instance — asked, awaiting approval; once deployed,
   live-verify a real `/v1/answers` call and reconsider flipping
   `KNOWLEDGE_PROVIDER=ragcore` in Fleet Ops. (2) task #86's remaining n8n pieces (Summarize
-  + report-result node, publish) is the only open item from the earlier RAGcore/n8n work —
-  last attempt hit an unexplained 401 calling n8n's REST API directly and was abandoned to
-  prioritize task #96; needs a fresh approach. (3) MCP Hub: registry push + production
-  deployment of the now-committed connector remain separate, explicitly-gated checkpoints.
-  WF4's own timeout/retry gap remains open, deferred, non-blocking.
+  + 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
+  browser automation side; needs either the user's own direct n8n session or an infra
+  look at the n8n deployment before any further automated editing is attempted. (3) MCP
+  Hub: registry push + production deployment of the now-committed connector remain
+  separate, explicitly-gated checkpoints. WF4's own timeout/retry gap remains open,
+  deferred, non-blocking.