M9: MCP Hub locale/correlation propagation, real Hub health check, fix stale test image

Fixed two concrete gaps in the MCP knowledge-search endpoint: no locale field
existed at all (now nl-BE/en-GB/fr-BE, wired to the knowledge provider's
existing language param), and the correlation ID was always freshly minted,
ignoring any inbound X-Correlation-Id header. Added a shared dependency and
applied it to all four MCP endpoints so Fleet Ops's own audit log preserves
the Hub's real correlation ID end to end.

MCP_HUB_BASE_URL/MCP_PROVIDER_ID were declared in .env.example but never read
anywhere. Since the Hub's own registration is catalog-driven (it never needs
Fleet Ops to push a registration call), wired mcp_hub_base_url for a real Hub
reachability health check instead of an unneeded self-registration call.

Renamed Fleet Ops's own internal audit tool labels mobilityops_* -> fleet_ops_*
(mirrored in contracts/mcp-tools.json with mobilityops_* kept as deprecated
aliases); documented that the live Hub connector's own dotted tool namespace
is a separate, Hub-owned naming layer, deliberately not touched.

Automation page's MCP card now shows real evidence (last tool/client/count/
timestamp, honest no-evidence state) instead of just the registration flag.

Also fixed a real methodology gap found mid-session: compose.yaml's api
service has no bind mount, so `docker compose run --rm api` silently tests a
stale image until rebuilt. Re-ran every local gate after rebuilding; fixed one
genuinely stale test assertion and two lint line-length errors surfaced by
that rebuild. 176 tests passing, ruff clean, mypy clean (50 files).

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

docs/10-mcp-hub-integration.md

@@ -6,20 +6,44 @@ Publish four read-only MobilityOps capabilities through the existing central ITW
 
 ## Provider registration
 
-- provider ID: `mobilityops`
-- API base: configurable internal MobilityOps API URL
-- authentication: scoped service token
+- provider ID: `mobilityops` (registered on the Hub side; the Hub's own registration is
+  catalog-driven — it reconciles its catalog into the gateway, Fleet Ops never pushes a
+  registration call)
+- API base: internal Fleet Ops API URL, reached via `MCP_HUB_SERVICE_TOKEN` auth
+- authentication: scoped service token (`X-Service-Token`), plus `X-Client-Id`
 - mode: read-only
-- required scope: `mobilityops.read`
+- **Confirmed live in production** on the ITWorx MCP Hub's own deployment (Tower), with
+  a real contract fix already applied there (`vehicle.get`'s wire parameter normalized to
+  camelCase `vehicleRef`). `docs/final-integrations/current-state-audit.md` has the full
+  evidence.
 
 ## Tools
 
-The machine-readable definitions are in `contracts/mcp-tools.json`.
+The machine-readable definitions are in `contracts/mcp-tools.json`. The Hub's own live
+connector (`ITWorx_MCP_Hub` repo, `connectors/mobilityops/`) publishes these under its
+own dotted namespace — that naming is the Hub's to own, not Fleet Ops's:
 
-1. `mobilityops_get_operations_summary`
-2. `mobilityops_list_attention_vehicles`
-3. `mobilityops_get_vehicle_details`
-4. `mobilityops_search_knowledge`
+1. `mobilityops.operations.summary`
+2. `mobilityops.attention.list`
+3. `mobilityops.vehicle.get`
+4. `mobilityops.knowledge.search`
+
+Fleet Ops's own internal audit trail (`AuditEvent.metadata_json.tool`, visible on
+`/api/v1/audit?action=mcp_tool_request`) labels these calls `fleet_ops_get_operations_summary`,
+`fleet_ops_list_attention_vehicles`, `fleet_ops_get_vehicle_details`,
+`fleet_ops_search_knowledge` — a separate, Fleet-Ops-owned naming layer for its own audit
+log, not the wire-level MCP tool name a client calls.
+
+`search-knowledge` accepts a `locale` field (`nl-BE` | `en-GB` | `fr-BE`, default
+`en-GB`) that is passed straight through to the active knowledge provider.
+
+## Correlation ID
+
+The inbound `X-Correlation-Id` header (set by the Hub, itself either forwarding the
+MCP client's ID or minting one) is preserved through Fleet Ops's own handling and audit
+log; Fleet Ops only mints a fresh correlation ID when none is supplied or the supplied
+value isn't a valid UUID. See `get_correlation_id` in
+`backend/app/api/routers/mcp_integrations.py`.
 
 ## Routing