fix: derive demo-manifest MCP Hub status from real tool-call evidence

The demo manifest still reported the MCP Hub integration as operational purely
because MCP_HUB_REGISTRATION_ENABLED was set, while the integration status page
had already moved to evidence-based status in Batch 4. Registration is
catalog-driven on the Hub's side, so the flag alone proves nothing; reuse
derive_mcp_hub_status() so "operational" requires real recorded mcp_tool_request
calls.

No change to the MCP integration contract: the four read-only routes, service
token and client id handling, inbound X-Correlation-Id preservation, the locale
field on search-knowledge and the provider/correlation_id response fields were
verified as already correct at deployed revision 727c19a and left untouched.

docs/demo-release/demo-concept.md

@@ -65,9 +65,11 @@ generated and kept fresh across resets.
   `RAGcoreKnowledgeProvider` HTTP adapter exists and is unit-tested, ready to take over
   the same interface once a real RAGcore backend is available — swapping providers is a
   configuration change (`KNOWLEDGE_PROVIDER`), not a UI change.
-- **ITWorx MCP Hub**: not connected. Registration is disabled by default
-  (`MCP_HUB_REGISTRATION_ENABLED=false`) and the UI always shows "Not connected" —
-  never a fabricated successful registration.
+- **ITWorx MCP Hub**: the UI reports "Operational" only when Fleet Ops has really
+  recorded `mcp_tool_request` calls in its own audit log. `MCP_HUB_REGISTRATION_ENABLED`
+  on its own never makes it operational — registration is catalog-driven on the Hub's
+  side, so the flag alone is not evidence of anything, and a successful registration is
+  never fabricated.
 
 ## Where to go next