docs: record the MCP Hub go-live fix and evidence

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

PROJECT_STATE.md

@@ -2058,3 +2058,45 @@ dashboard section was always the same static 4 rows.
   `master`, pushed, and deployed to Unraid (`.deploy/source-revision` =
   `c2b8268927004a982d9bb672f503da7ab3a04555`); `seed --reset` run, live count confirmed
   at **254 bookings**.
+
+## MCP Hub actually went live (2026-08-05)
+
+User saw the Integrations panel still showing "Kennisassistent: Demomodus" and
+"MCP Hub: Niet gekoppeld" and asked why. Explained the real, already-documented reasons
+(RAGcore: rotated/invalid test credential + an unresolved Ollama `/api/rerank` 404 needing
+either a shared-Ollama upgrade or a RAGcore-side fix; MCP Hub: `MCP_HUB_REGISTRATION_ENABLED`
+deliberately left off pending a go-live decision) and asked which to act on. **User chose:
+flip the MCP Hub flag live; leave RAGcore alone.**
+
+- Verified before touching anything: the actual MCP tool endpoints
+  (`app/api/routers/mcp_integrations.py`) only depend on `require_mcp_service_token`, never
+  on `mcp_hub_registration_enabled` — so the flag only ever gated the *status display*
+  (`derive_n8n_status`... `derive_mcp_hub_status`), never real functionality. Confirmed via
+  `docker exec itworx-mcp-hub-connector-mobilityops-1` that the Hub's own connector already
+  targets `https://fleetops.itworx.tech` (confirmed via Nginx Proxy Manager's `60.conf` to be
+  this exact `192.168.10.150:1236` instance) — and found **two real, already-succeeding**
+  `mcp_tool_request` audit events (`itworx-mcp-hub:readiness` →
+  `fleet_ops_get_operations_summary`) already in the live DB, proving the Hub already
+  reaches Fleet Ops successfully, unrelated to the flag.
+- Flipped `MCP_HUB_REGISTRATION_ENABLED=true` in the live `.env`, force-recreated `api` —
+  **status stayed `registration_enabled: false`**. Root cause: `compose.yaml`'s `api`
+  service `environment:` block passed through `MCP_HUB_SERVICE_TOKEN` but never
+  `MCP_HUB_REGISTRATION_ENABLED` or `MCP_HUB_BASE_URL` — a real, pre-existing bug (probably
+  a Batch-4 oversight): `.env` had always been a no-op for these two, silently. Fixed by
+  adding both to `compose.yaml` (`c2b8268`... committed as `529e736`), redeployed.
+- **Live-verified after the fix**: `/api/v1/integrations/status` → `mcp_hub.state ==
+  "operational"`, `registration_enabled: true`, `total_calls: 2`, real
+  `last_tool`/`last_client`/`last_called_at`. Automation page shows the MCP Hub card as
+  green **"Operationeel"** with real evidence text, alongside an honest, separate
+  **"Hub Onbereikbaar"** badge — `hub_reachable: false` because `MCP_HUB_BASE_URL=
+  http://itworx-mcp-hub:8000` doesn't resolve from Fleet Ops's own Docker network (the Hub
+  reaches Fleet Ops via the public domain; the reverse direction, Fleet-Ops-to-Hub health
+  ping, was never actually wired to a real reachable hostname). Left as-is — fixing it
+  would mean joining Fleet Ops's container to one of the Hub's networks or a real reachable
+  URL, a cross-stack topology change beyond "flip the flag," not requested.
+- Committed, pushed, merged (fast-forward) to `master`, redeployed to Unraid
+  (`.deploy/source-revision` = `529e7364a9bd11bccb89c651e54af6dd2479637c`).
+- **Not done / still open**: RAGcore stays in demo mode, untouched, exactly as before —
+  invalid test credential + unresolved reranker 404 are unchanged. `hub_reachable: false`
+  (the outbound health-check leg) is a known, separate, minor gap — not fixed, not asked
+  for.