docs: record polish fixes, merge, and second deploy evidence

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

PROJECT_STATE.md

@@ -2009,3 +2009,52 @@ new pages.
   **33 data-quality issues** (21 CSV + 12 scan-found, unchanged from before this fix).
 - **Not done**: no PR opened from this branch to `master` this session (master was merged
   once, earlier, at `3808bbe` — this new commit is not yet on `master`).
+
+## Merged to master and deployed again (2026-08-05)
+
+`feat/fleet-ops-final-integrations` fast-forward merged into `master` (2 commits, 0
+conflicts), pushed, then deployed to Unraid (`.deploy/source-revision` =
+`4faac24b5aabf6cfaecff71ffecf132b03c417f1`) and live-verified in all three languages.
+
+## Visual/content polish: form alignment, maintenance text, static movements (2026-08-05)
+
+User flagged, from screenshots: form-field alignment on the data-quality detail screens
+wasn't clean, and (separately, spotted in a follow-up screenshot) the "Bewegingen vandaag"
+dashboard section was always the same static 4 rows.
+
+- **Form alignment root cause**: the shared label-stacking CSS rule
+  (`.filters label, .return-form label { display:flex; flex-direction:column; ... }`)
+  never covered `.form-grid label` or the standalone note `<label>` wrapping a `<textarea>`
+  in `DataQualityIssueDetail.tsx`'s `MissingFieldPanel`/`OdometerRegressionPanel`/
+  `BookingOverlapPanel` — those fell back to default inline browser layout (label text
+  touching the input, mismatched column widths). Extended the selector to
+  `.form-grid label, .panel label:has(> textarea)` (and the matching input-styling rule)
+  rather than touching JSX; `:has()` was already an accepted pattern in this codebase
+  (`.choice-card:has(input:checked)`).
+- **Found and fixed a related bug while investigating a screenshot**: the vehicle
+  maintenance tab rendered the raw seed `summary` field verbatim
+  ("Synthetic scheduled service record"/"Synthetic minor repair record") in every locale,
+  bypassing i18n entirely — and it was 1:1 redundant with the already-translated
+  `category` anyway. Replaced it with the record's real `odometer_km`, mirroring the
+  sibling Inspections tab's established pattern (`VehicleDetail.tsx`).
+- **"Today's movements" was always the identical 4 bookings** (2 returns, 2 departures)
+  on every single reset, because only 4 rows in `seed/bookings.csv` were anchored to
+  land on the seed's "today". Added 8 more (`BK-T-001..008`) anchored the same way,
+  spread across the day, using 8 vehicles confirmed to have zero existing
+  reserved/active bookings (no overlap risk). Booking count 246 → 254.
+- Note for anyone extending this further: while checking the fix in the browser, Chrome's
+  own translate feature auto-translated the fr-BE page into garbled Dutch (mis-rendering
+  "Entretien" as "Interview") — a browser artifact, not an app bug. Switching the app's
+  own language selector away from French stopped it; don't mistake this for a real
+  localization regression if it recurs during manual browser testing.
+- **Gates**: `pytest -q` — **186 passed** (updated the seed-count assertion to 254 and
+  strengthened `test_seed_today_movements_are_a_credible_mix` to require ≥5
+  departures/≥5 returns across >4 distinct vehicles, up from the old ≥2/≥2 floor);
+  `ruff check .` clean; `mypy app` clean; `npm run build` clean.
+- **Browser-verified** locally and live after deploy: form fields stack label-above-input
+  with consistent widths, the maintenance tab shows a real odometer figure, and
+  "Bewegingen vandaag" shows all 12 movements spread through the day.
+- **Pushed** `feat/fleet-ops-final-integrations` → `c2b8268`, merged (fast-forward) into
+  `master`, pushed, and deployed to Unraid (`.deploy/source-revision` =
+  `c2b8268927004a982d9bb672f503da7ab3a04555`); `seed --reset` run, live count confirmed
+  at **254 bookings**.