polish: rebrand to Fleet Ops, add trilingual i18n, adaptive demo guide, and UX overhaul

Rebrands the product from MobilityOps to Fleet Ops across the UI, backend defaults and
knowledge base, and makes nl-BE/en-GB/fr-BE full first-class languages: i18next with
eager-bundled per-namespace resources, a persisted accessible language switcher (topbar
and mobile drawer), locale-aware date/number formatting, and a coverage test that fails
the build on any missing or empty translation key.

Backend dynamic content (demo scenarios, blocked-reason text, integration status) moves
from fixed English/Dutch prose to stable message codes + params so the frontend can
localize it; the demo knowledge base gains a fully translated NL/EN/FR procedure corpus
(11 documents each) with per-language retrieval and localized evidence-state messages.

The Demo Guide becomes breakpoint-adaptive: a docked rail on extra-wide desktop, a
floating panel that auto-collapses to a persistent, closable progress chip on standard
desktop/tablet, and a collapsed/half/full bottom sheet on mobile -- with scroll+focus+
highlight on "go to this step", Escape handling, and reduced-motion support.

The Data Quality Workbench gets accessible choice-card decisions with a clear primary/
secondary/tertiary action hierarchy; the Automation ledger groups repeated successes and
uses meaningful short refs; the Audit trail groups events by correlation id with human
action labels and readable before/after diffs. Attention Queue, Today's movements,
Vehicles, Bookings and Data Quality rows are fully clickable (stretched-link pattern)
with independent secondary links, keyboard support and mobile touch targets.

Fixes a topbar overflow on mobile caused by the new language switcher (moved into the
mobile drawer at <=960px) and two dangling aria-labelledby references introduced this
session. Updates all affected Playwright specs for the new nl-BE default and the new
Audit/DemoGuide DOM structure, and adds new i18n-coverage, demo-guide-adaptive and
clickable-rows specs. 131 backend tests, Ruff and mypy, and 71 Playwright tests pass.

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

knowledge/procedures/en-GB/01-vehicle-checkout.md

@@ -0,0 +1,21 @@
+---
+document_id: vehicle-checkout-procedure
+title: Vehicle checkout procedure
+version: "1.2"
+effective_date: 2026-06-01
+department: Rental Operations
+status: active
+---
+# Vehicle checkout procedure
+
+## 1. Required checks
+
+Before a vehicle leaves the site, the rental employee must confirm the active booking, customer identity, driving licence and required signed documents. The recorded starting odometer must not be lower than the vehicle's current canonical odometer.
+
+## 2. Vehicle condition
+
+Complete the checkout inspection, record fuel level and visible pre-existing damage, and confirm that no blocking maintenance or data-quality issue is open.
+
+## 3. Release
+
+Only a vehicle with an approved checkout inspection may be set to rented. When a critical discrepancy is found, keep the vehicle blocked and escalate to Operations.

knowledge/procedures/en-GB/02-vehicle-return.md

@@ -0,0 +1,25 @@
+---
+document_id: vehicle-return-procedure
+title: Vehicle return procedure
+version: "2.0"
+effective_date: 2026-07-01
+department: Rental Operations
+status: active
+---
+# Vehicle return procedure
+
+## 1. Register the return
+
+Open the active booking and record the ending odometer, fuel level, cleanliness, visible damage, technical warnings and relevant notes.
+
+## 2. Validate the reading
+
+A submitted odometer below the previous canonical reading must never replace the canonical value. Register the inspection, create a data-quality issue and request human review.
+
+## 3. Determine next state
+
+Damage or a technical warning requires a blocked state. A reached service threshold requires maintenance. Otherwise the vehicle moves to cleaning before it can become available.
+
+## 4. Follow-up
+
+The return automation may create a cleaning or maintenance follow-up, but MobilityOps remains the source of truth for the vehicle state.

knowledge/procedures/en-GB/03-damage-handling.md

@@ -0,0 +1,21 @@
+---
+document_id: damage-procedure
+title: Damage handling procedure
+version: "1.3"
+effective_date: 2026-06-15
+department: Operations
+status: active
+---
+# Damage handling procedure
+
+## 1. Immediate actions
+
+When a vehicle returns with visible or reported damage, mark damage in the return inspection, add a concise factual description and keep the vehicle blocked. Do not promise the customer a repair cost or liability decision.
+
+## 2. Evidence
+
+Record at least four photographs in the source inspection system: full affected side, close view, wider context and vehicle registration. MobilityOps may store only the evidence reference in this PoC.
+
+## 3. Escalation
+
+Create an Operations review before any new rental. A vehicle with unresolved damage may not be marked available even when a future booking exists.

knowledge/procedures/en-GB/04-odometer-anomalies.md

@@ -0,0 +1,21 @@
+---
+document_id: odometer-anomaly-guideline
+title: Odometer anomaly guideline
+version: "1.1"
+effective_date: 2026-05-20
+department: Operations
+status: active
+---
+# Odometer anomaly guideline
+
+## 1. Lower reading
+
+If a new reading is lower than the canonical odometer, preserve the submitted reading as evidence but do not lower the canonical value. Check for digit transposition, incorrect vehicle selection or a source-system import error.
+
+## 2. Resolution
+
+An Operations Manager may resolve the issue after checking the original inspection. Correct only the erroneous inspection or source mapping; do not rewrite valid historical readings.
+
+## 3. Escalation threshold
+
+Any unexplained reduction or a single increase above 2,500 kilometres during one rental requires review.

knowledge/procedures/en-GB/05-cleaning-checklist.md

@@ -0,0 +1,21 @@
+---
+document_id: cleaning-checklist
+title: Vehicle cleaning checklist
+version: "1.4"
+effective_date: 2026-06-10
+department: Fleet Preparation
+status: active
+---
+# Vehicle cleaning checklist
+
+## 1. Interior
+
+Remove waste, inspect upholstery, clean kitchen and sanitary surfaces, and confirm that the inventory checklist is complete.
+
+## 2. Exterior
+
+Inspect windows, lights, tyres and bodywork while cleaning. Report newly observed damage rather than silently completing the task.
+
+## 3. Completion
+
+Cleaning completion alone does not make a blocked or maintenance vehicle available. MobilityOps derives availability from all active restrictions.

knowledge/procedures/en-GB/06-maintenance-escalation.md

@@ -0,0 +1,21 @@
+---
+document_id: maintenance-escalation
+title: Maintenance escalation procedure
+version: "1.1"
+effective_date: 2026-04-01
+department: Workshop
+status: active
+---
+# Maintenance escalation procedure
+
+## 1. Triggers
+
+Escalate when a technical warning is reported, the service threshold is reached, a safety-related defect is observed or an existing maintenance block remains unresolved.
+
+## 2. State
+
+Set or retain the maintenance state. A future booking does not override a maintenance restriction.
+
+## 3. Release
+
+Only an authorised maintenance completion record and the absence of other blocking issues permit the vehicle to proceed to cleaning or availability.

knowledge/procedures/en-GB/07-customer-documents.md

@@ -0,0 +1,21 @@
+---
+document_id: customer-document-requirements
+title: Required customer documents
+version: "1.0"
+effective_date: 2026-07-01
+department: Rental Operations
+status: active
+---
+# Required customer documents
+
+## 1. Checkout requirements
+
+The customer identity and valid driving licence must be verified in the source process before checkout. Required contractual documents must be signed.
+
+## 2. Data minimisation
+
+MobilityOps records only completion status and source references for this PoC. It does not store identity-document images.
+
+## 3. Missing information
+
+A booking with incomplete required documents is not ready for checkout and must appear as an attention item.

knowledge/procedures/en-GB/08-privacy.md

@@ -0,0 +1,21 @@
+---
+document_id: privacy-guideline
+title: Operational privacy guideline
+version: "1.0"
+effective_date: 2026-03-01
+department: Management
+status: active
+---
+# Operational privacy guideline
+
+## 1. Minimum access
+
+Employees may access only the customer and booking information required for their role. External AI tools receive no unrestricted customer dataset.
+
+## 2. Knowledge platform
+
+Do not ingest customer personal data, booking notes or identity documents into the procedure knowledge collection. The collection is limited to approved internal guidance.
+
+## 3. Logging
+
+Audit action metadata and source references, but avoid copying unnecessary personal data into technical logs.

knowledge/procedures/en-GB/09-booking-conflicts.md

@@ -0,0 +1,21 @@
+---
+document_id: booking-conflict-procedure
+title: Booking conflict procedure
+version: "1.2"
+effective_date: 2026-06-20
+department: Operations
+status: active
+---
+# Booking conflict procedure
+
+## 1. Detection
+
+Two reserved or active bookings for the same vehicle may not overlap. Imported legacy conflicts must be flagged as data-quality issues.
+
+## 2. Resolution
+
+Operations reviews both bookings, confirms source-system ownership and reassigns or cancels one booking in the authoritative booking system. MobilityOps records the reviewed outcome.
+
+## 3. Safety
+
+Do not automatically cancel a customer booking based only on an inferred conflict.

knowledge/procedures/en-GB/10-roles-and-escalation.md

@@ -0,0 +1,21 @@
+---
+document_id: roles-and-escalation
+title: Roles and escalation matrix
+version: "1.0"
+effective_date: 2026-06-01
+department: Management
+status: active
+---
+# Roles and escalation matrix
+
+## Rental Employee
+
+May view assigned operational records, complete checkout and return inspections, and consult procedures. May not merge customer records or reset the demo environment.
+
+## Operations Manager
+
+May review all attention and data-quality issues, merge confirmed duplicate customers, retry workflow delivery and reset the synthetic demo.
+
+## Service integrations
+
+n8n, RAGcore and ITWorx MCP Hub use separate scoped identities. Service identities do not inherit an interactive user role.

knowledge/procedures/en-GB/11-vehicle-availability.md

@@ -0,0 +1,21 @@
+---
+document_id: vehicle-availability-procedure
+title: Vehicle availability procedure
+version: "1.0"
+effective_date: 2026-07-01
+department: Rental Operations
+status: active
+---
+# Vehicle availability procedure
+
+## 1. Conditions
+
+A vehicle may be set to available only when no blocking condition remains: no open damage, no unresolved technical warning, no pending maintenance block and no open critical data-quality issue against the vehicle.
+
+## 2. Cleaning is not sufficient
+
+Completing the cleaning checklist alone does not make a vehicle available. Availability is derived from the combined state of cleaning, maintenance and data-quality checks, not from any single step.
+
+## 3. Confirmation
+
+An authorised employee confirms the final check and the vehicle status changes to available. The change is recorded in the audit trail with the checks that were confirmed clear.