feat(trainer): phase-B body-type classifier — trainer job on the collector host + the classifier stage on the booth

apps/trainer (parking-trainer): inspect / train / evaluate / publish. Reads the wash
collector's SQLite + crops read-only off its volume; time split (validation = newest
slice); thin classes dropped; damped class weights; `features` mode (frozen ImageNet
backbone, on-disk feature cache, seconds to retrain) and `finetune` mode (light
augmentation). CPU-only torch from PyTorch's wheel index. ONNX export checked against
the torch model; NO model file below the validation floor (exit 3, report still written);
exit 2 = not enough labels. `evaluate` scores a shipped model on labels reviewed after
training + the unlabelled pile; `publish` PUTs a version folder to a Gitea generic package.
Light core deps; the `train` extra is heavy — CI syncs without it, torch tests skip.

apps/vision: BodyTypeClassifier (bodytype.onnx + sidecar = the preprocessing contract:
crop margin, input size, RGB 0-255, normalisation inside the graph) and
RefinedVehicleDetector over YOLOX — refines only `car` or a class the classifier trained
on, min-confidence, `detector_class` on the result; path set but no file = phase B off
without an error; a broken file is a health detail. models/bodytype.version (tracked,
empty) pins the published version the Dockerfile fetches at build (BuildKit secret;
a pin that cannot be fetched fails the build). Verified: a trainer model gives identical
probabilities inside the vision service; both images built and smoke-tested.

Delivery: parking-trainer image in build-images.yml, the `trainer` compose profile on the
collector stack (CPU, read-only data, TRAINER_OUT), commented TRAINER_OUT/PUBLISH_TOKEN in
the wash-collector stack, .dockerignore for both Python contexts, trainer deps synced in CI.

Wiki: bodytype-classifier-training rewritten as built (+ one fleet model not per site,
secrets/access, where the crops live), opencv-anpr-service §Phase B, vision-review-outbox,
vision-service-packaging, fleet-deployment-komodo, index, log.

Claude-Session: https://claude.ai/code/session_01FWncR69HgGPuei1dLrW3cU

wiki/entities/opencv-anpr-service.md

@@ -252,7 +252,8 @@ service's `/health` each tick and shows a **"Vision" chip** in the booth footer
 ## Vehicle body type (advisory) — the vehicle stage, phase A (2026-09-06)
 
 > Phase B (the classifier that knows SUV from sedan), its training loop and the hardware it runs on
-> are decided on [[bodytype-classifier-training]] — not built yet.
+> are on [[bodytype-classifier-training]] — built 2026-09-07, see §Phase B below; no model is
+> pinned yet (the stage is off until the first published version).
 
 `/analyze` populates `vehicle.body_type` + `vehicle.confidence` from the shared vocabulary
 (car, sedan, hatchback, suv, minivan, pickup, van, truck, bus, motorcycle). Node records it beside
@@ -293,3 +294,31 @@ read. Composed `model_version` reads `<plate>+yolox:yolox_s.onnx@640`.
   operator's picks (untrusted — [[threat-model]]) but a trusted reviewer's, gathered through the
   [[vision-review-outbox]]. Expect 85–95 % on frontal gate views once tuned — enough to flag,
   never to bill, which is why the flag records and the site threshold exists.
+
+### Phase B — the body-type classifier stage (built 2026-09-07)
+
+`vehicle.py` gained a second stage: `BodyTypeClassifier` loads `bodytype.onnx` + its
+`bodytype.json` sidecar (produced by `apps/trainer`, [[bodytype-classifier-training]] §The
+contract) and `RefinedVehicleDetector` composes it over the YOLOX detector — the detector still
+finds and picks the vehicle, the classifier answers on its crop. `crop_vehicle` mirrors the
+outbox's `makeReviewCrop` (box + the sidecar's margin, plate strip Gaussian-blurred) so the
+booth sees what the model was trained on; resize is OpenCV `INTER_AREA` at the sidecar's
+`input_size`, raw RGB 0–255 in, normalisation inside the graph.
+
+- **Rule:** the classifier runs only when the detector said `car` **or** a class the classifier
+  trained on; a truck/bus/motorcycle it never saw is left alone. Below
+  `VISION_VEHICLE_CLASSIFIER_MIN_CONFIDENCE` (0.6) the detector's class stands. When the stage
+  ran, `vehicle.detector_class` carries the coarse class (Node ignores it today; the collector
+  could show it). `model_version` reads `<plate>+yolox:…+bodytype:<version>`.
+- **Config:** `VISION_VEHICLE_CLASSIFIER_PATH` (the image sets `/app/models/bodytype.onnx`) and
+  the min-confidence. **Path set but no file = the normal state before the first model** —
+  phase A only, one log line, *no* `/health.detail` error. A file that fails to load IS an error
+  in `detail` (`classifier: …`), and a classifier that throws per frame is caught, noted, and the
+  detector's answer returned — the plate read is never at risk.
+- **Bake:** `apps/vision/models/bodytype.version` (tracked; empty) pins the published version the
+  Dockerfile fetches from the Gitea generic package registry (BuildKit secret `bodytype_auth`);
+  a pin that cannot be fetched fails the build, an empty pin passes with phase B off.
+- **Tests** (`tests/test_vehicle.py`): crop margin/clamp/blur, the refine rule (car → suv when
+  confident; unsure → detector's class; unknown bus untouched; a classifier that knows trucks may
+  override a truck), a throwing classifier survives and is reported, missing files → not ready,
+  and the factory skips a missing model without an error.