fix(perception): stabilize replay body frame

docs/22_MILESTONE_4_OBJECT_CENTRIC_RECORDED_REALTIME_CV.md

@@ -917,7 +917,8 @@ the following M4.6 replay-only threat phase.
 
 ### 2026-08-05 — M4.6 dual-evidence replay threat
 
-M4.6 is closed by `k1link.perception.threat` and the immutable replay builder in
+M4.6 is closed by the corrected v2 implementation in
+`k1link.perception.threat` and the immutable replay builder in
 `k1link.perception.threat_replay`:
 
 - `DualEvidenceReplayThreatProvider` consumes the canonical `LocalObstacleMap`;
@@ -931,37 +932,62 @@ M4.6 is closed by `k1link.perception.threat` and the immutable replay builder in
 - the versioned replay profile fixes a virtual `1.0 × 0.6 m` body, nominal
   `1.25 m` sensor height, `8 m` forward corridor and `5 s` bounded prediction
   horizon; all documents retain `replay-simulated`, physical-collision false and
-  actuation false authority.
+  actuation false authority;
+- the collision frame is a gravity-stable virtual `base_footprint`: its vertical
+  origin comes from the recorded local surface, its up axis remains the vendor
+  SLAM map gravity axis, and its forward axis follows the smoothed recorded
+  trajectory while being checked against the calibrated camera optical axis;
+- local surface height, slope or route/camera disagreement outside the admitted
+  bounds rejects that replay frame instead of rotating the world or silently
+  calculating a corridor from unqualified geometry.
 
-The accepted immutable result is
-`m4-threat-replay-7e1613a3ea35638b5ea7a3f7c1c78fe9eba1a3adae540b652dec167f815d45b2`:
+The original result
+`m4-threat-replay-7e1613a3ea35638b5ea7a3f7c1c78fe9eba1a3adae540b652dec167f815d45b2`
+is withdrawn and superseded. It incorrectly used the instantaneous LiDAR frame
+as a virtual body frame, assumed LiDAR `+X` was vehicle forward even though the
+recorded K1 calibration places camera-forward near LiDAR `-Y`, and rendered the
+SLAM world with the handheld sensor roll and pitch. Its acceptance only proved
+artifact availability, not body/corridor geometric validity.
+
+The corrected accepted immutable result is
+`m4-threat-replay-78a06d96c4db5263dc63fc4e6e067c07fc81370d3f5085ff43361af89cec1e9e`:
 
 - `4,489 / 4,489` frames completed, zero failed;
 - `27,299` current metric, `37,995` stale/held and `10,158` camera-only evidence
   publications were each assessed exactly once;
-- decisions: `8,010 threat`, `6,610 not-threat`, `60,832 unknown`;
-- `21,958` geometry-only assessments remained in the decision path without a
+- `3,928` source-bound body-frame inputs were available, `3,861` qualified and
+  `67` were rejected: `65` for unqualified sensor height and `2` for excessive
+  route/camera disagreement; `561` source-unavailable frames remain explicitly
+  accounted for;
+- calibrated camera-forward versus route-forward agreement was `8.439°` p95,
+  with `24.252°` as the maximum accepted value under the fixed `25°` limit;
+- decisions: `2,716 threat`, `10,700 not-threat`, `62,036 unknown`;
+- `21,690` geometry-only assessments remained in the decision path without a
   class requirement;
 - deterministic fixtures passed `9 / 9`; all four critical fixtures avoided a
   false `not-threat` outcome;
-- local uncapped execution measured `132.812 FPS`; provider latency was
-  `3.932 ms` p50 and `17.567 ms` p95;
+- local uncapped execution measured `278.601 FPS`; provider latency was
+  `1.656 ms` p50 and `6.099 ms` p95;
 - deterministic frame, visual and fixture ledgers are sealed by SHA-256
-  `bf690358efb45c323db7172251074b33c3ef7ede6ae99bd8d3da53cfba86b142`,
-  `fb022c6efd84f27c0916a6c87887443c9b43993ac4b1f9910332433152533dea`
-  and `e217b61f3e8cf444f2620c0d815c18b2131eaafca29352bf12f78e05db96ee13`.
+  `d55e7651f0b16a62c6b61c5cb2358dd8dff87dbfa57a59e9ec350bc38b156bc1`,
+  `957c35d46ae30143beb6b2f26f8f722853ef2a1e91a41d5dc1a03fbf723a54e0`
+  and `ffa6f6a0f82faa7b6304aca5d8a62e1bb2730b484929d20d66005db9a2b4fa20`.
 
 The standard LAB catalog exposes the exact result with a common evidence viewer:
 full recorded VIDEO, exact CAMERA samples with ranges/unknown boxes, and the same
 32 synchronized LiDAR point-cloud samples in interactive 3D and plan view. The
 recorded box overlay was extracted from E46C into a reusable component rather
-than copied into an M4-specific renderer. Visual availability is evidence for
-inspection, not independent ground truth.
+than copied into an M4-specific renderer. Regression frames `138` and `274`,
+which exposed the original rotated-world defect, are mandatory members of the
+visual ledger. Visual availability is evidence for inspection, not independent
+ground truth.
 
 M4.6 does not close moving/static correctness or object-presence correctness;
 those remain the independent M4.8 gate. It also does not authorize a physical
-mount, live K1, navigation, collision safety or commands. M4.7 is now the next
-implementation phase.
+mount, live K1, navigation, collision safety or commands. On a physical vehicle,
+the replay-derived virtual frame must be replaced by one measured rigid
+`T_body_from_sensor`; this does not change the downstream obstacle or threat
+contracts. M4.7 is now the next implementation phase.
 
 ## Implementation order
 

docs/adr/0040-dual-evidence-replay-threat-boundary.md

@@ -17,6 +17,13 @@ qualified LiDAR-to-body mount. A recorded threat experiment therefore needs an
 explicit virtual geometry without weakening the physical rig contract in ADR
 0035.
 
+The first M4.6 implementation incorrectly treated the instantaneous LiDAR frame
+as the virtual body frame. The K1 calibration proves that camera-forward is near
+LiDAR `-Y`, not `+X`, and the handheld pose contains real roll and pitch. That
+made the replay corridor approximately 90 degrees off the route and rotated the
+SLAM world with the operator's hand. Result `m4-threat-replay-7e1613...` is
+superseded and is not admissible M4.6 evidence.
+
 ## Decision
 
 Mission Core threat assessment consumes two independent evidence paths:
@@ -48,6 +55,26 @@ only with `replay-simulated` authority. They do not populate or qualify
 `missioncore.rig-geometry/v1`, and they cannot support physical collision,
 navigation, safety or actuation claims.
 
+The virtual collision frame is a gravity-stable `base_footprint`, not the
+instantaneous sensor frame:
+
+- the K1 vendor SLAM map remains the stable world in which mapped points live;
+- the rolling local-surface model supplies only the vertical ground origin and
+  a quality check, not a permanent level-world assumption;
+- forward is the smoothed SLAM trajectory tangent and is independently checked
+  against the calibrated camera optical axis;
+- unavailable height, excessive local slope or camera/route disagreement makes
+  that frame unqualified instead of silently rotating the corridor;
+- a mounted vehicle replaces this replay-only derivation with one measured,
+  rigid `T_body_from_sensor`; the detector, obstacle map and threat policy do not
+  change.
+
+The sensor may therefore be mounted at a non-level angle or noncentral position
+as long as it is rigid and its one-time body extrinsic is known. Vehicle roll
+and pitch do not corrupt the SLAM map; a future 3D swept-volume planner may use
+`base_link`, while the current 2D corridor remains explicitly tied to
+`base_footprint`.
+
 ## Evidence and presentation
 
 The accepted replay must publish immutable frame, fixture, report and visual
@@ -57,6 +84,8 @@ ledgers. Visual evidence uses the common LAB viewer and reusable renderers:
 - exact camera samples with metric range or explicit missing range;
 - synchronized point cloud, occupied cells, virtual body and corridor in 3D and
   plan view;
+- mandatory regression frames `138` and `274`, which exposed the original
+  sensor/body-axis failure;
 - visible threat/not-threat/unknown and `replay-simulated` authority.
 
 Visuals are an inspection surface, not ground truth. Independent object-centric