docs: record the MCP Hub URL fix and RAGcore Procedure Sync go-live

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

PROJECT_STATE.md

@@ -2158,3 +2158,43 @@ and fixed for real rather than either blindly flipping the flag or refusing.
   get full generated answers again with zero further changes here, since `/v1/answers` is
   still tried first every time. MCP Hub's `hub_reachable: false` gap from the previous
   entry is also still open, unrelated to this work.
+
+## Cleaned up the two visible loose ends from going live (2026-08-05)
+
+User spotted two more things live: the Automation page showed MCP Hub as both
+"Operationeel" and "Hub Onbereikbaar" simultaneously, and 2 of 4 n8n workflows showed "no
+evidence yet."
+
+- **`MCP_HUB_BASE_URL` had the exact same wrong-hostname bug** as `RAGCORE_BASE_URL`
+  earlier this session: `itworx-mcp-hub:8000` doesn't resolve from Fleet Ops's network.
+  Found the real address via the same method (Nginx Proxy Manager config for
+  `mcp.itworx.tech` → `192.168.10.150:1100`), confirmed a real `200 {"status":"healthy"}`
+  from inside `mobilityops-api-1`, fixed live. `hub_reachable` is now `true` — the
+  contradiction is gone, both signals agree.
+- **"Workflow Error Handler" showing no evidence turned out to be correct, not a bug**:
+  it's already active/published; it just hasn't been triggered by a real production
+  failure yet. Explained this rather than manufacturing a fake failure to force a green
+  badge.
+- **"RAGcore Procedure Sync" was still genuinely unpublished** (a previous session's
+  deliberate go-live gate). With the user's explicit approval, published it for real: its
+  own `RAGcore Sync Token` n8n credential had gone stale from the same rotation as
+  earlier, so minted a fresh, dedicated, minimally-scoped (`sources:sync` only) credential
+  via RAGcore's admin panel, ran the workflow manually first (33 procedures synced, 0
+  failed, Fleet Ops registered the result), then published it to run on its real daily
+  schedule.
+- **That exposed a real, separate, now-stale bug**: `derive_n8n_status()` hardcoded this
+  workflow's evidence to `None`, with a comment explaining it was unpublished — true when
+  written, false the moment it went live. The workflow's own result-report callback
+  already writes a real `n8n_procedures_synced` audit event; wired that in as the
+  evidence source, the same pattern the scheduled scan and error handler already use.
+  Added a test proving the real callback now surfaces as evidence rather than staying
+  silently `None` forever.
+- **Gates**: `pytest -q` — **189 passed**; `ruff check .` clean; `mypy app` clean.
+- **Live-verified**: `known_workflow_count: 3/4` (only the error handler correctly still
+  shows none), Automation page shows "Synchronisatie kennisprocedures" as green
+  "Operationeel" with a real timestamp, MCP Hub shows only "Operationeel" with no
+  contradicting badge.
+- Committed/pushed/merged to `master` (`086dfed`), deployed to Unraid
+  (`.deploy/source-revision` = `086dfed9928d197173435162dd24b1eb8e78f055`).
+- Updated `n8n/workflows/MANIFEST.md`'s workflow 3 entry from "Inactive" to "Active /
+  Published" with this session's go-live evidence.