docs(perception): record M4.8R2 occupancy gate

docs/13_LIDAR_WORKER_PRODUCT_AND_ROADMAP.md

@@ -912,6 +912,17 @@ authority.
 Exit: local collision-space quality and deadline gates pass in replay and
 shadow. This still does not authorize control.
 
+M4.8R2 now supplies the bounded pre-shadow qualification for the first item.
+On eleven operator-assisted static passage anchors, the accepted current/rolling
+graph covers `6/11`, while the additive sealed low-step signal covers `10/11`;
+the critical `0–8 m` subset is `9/9`, four canonical engineering anchors remain
+matched and false-free count is zero. The item remains unchecked because this
+is not independent truth and the candidate is not yet part of the Worker
+pipeline. Its next gate is a full `4,489`-frame occupied-only Worker 006 shadow
+with FPS, latency, occupancy growth, component-count and capacity-drop bounds.
+Dynamic decay, Nav2 publication and planner-authoritative free space remain
+separate later work.
+
 ### L6 — alternative odometry/mapping
 
 This stage starts only when a source supplies unregistered sensor scans. Add

docs/17_PRODUCT_UI_AND_LAB_PRESENTATION_CANON.md

@@ -179,6 +179,13 @@ only on the annotated frame unless a separately evidenced and reviewable
 tracking result exists; ordinary model proposals and graph layers continue on
 their own full recorded timeline.
 
+M4.8R2 is the canonical static-occupancy example of this rule. Its report and
+eleven typed anchors bind to the accepted M4.7 LAB identity, use the same
+`VIDEO/CAMERA/3D/PLAN/SEMANTICS` timeline and add no renderer or transport. A
+qualified anchor means the additive occupied-only candidate has LiDAR support
+inside that exact reviewed camera extent; it does not turn the extent into a 3D
+collider or grant clearance, free-space, navigation or safety authority.
+
 A third perception instrument is a product-surface change. It requires explicit
 product-owner agreement before implementation and cannot be introduced by a LAB
 adapter, result component or experiment configuration.

docs/22_MILESTONE_4_OBJECT_CENTRIC_RECORDED_REALTIME_CV.md

@@ -1475,6 +1475,35 @@ candidate acceptance, production acceptance, navigation, safety, commands and
 actuation authority remain false. The next action is operator adjudication in
 the existing M4.8 review instrument.
 
+### 2026-08-26 — M4.8R2 conservative static-occupancy qualification
+
+M4.8R2 moves the small-static problem out of semantic detector tuning and into
+the existing LiDAR occupancy boundary. RF-DETR, native fisheye input and its
+risk taxonomy are unchanged. The deterministic qualification consumes the
+accepted M4.7 current/rolling graph plus the frozen M4.8R1 operator-assisted
+static anchors. It evaluates one already sealed local-surface signal,
+`point_step_candidate`, only as additive occupied-or-unknown evidence. It never
+clears a cell, claims free space, starts detector inference or uses the GPU.
+
+Immutable result
+`m48-static-occupancy-qualification-568024554cff011332ff19ca4739f70555a6232c0607dec2a71be6db408ea69a`
+contains `11` static passage anchors. The accepted graph qualifies `6/11`; the
+additive low-step candidate qualifies `10/11`. In the critical `0–8 m` band the
+change is `6/9 → 9/9`; in the `8–12 m` approach band it is `0/2 → 1/2`. All
+four existing canonical engineering anchors remain matched and the result
+contains zero false-free claims. One approach anchor remains explicitly
+`unresolved-unknown-never-free`.
+
+This is candidate-visible development evidence, not independent truth or a
+production cutover. The result accepts only a bounded next action: integrate
+the low-step contribution as an occupied-only Worker shadow and replay all
+`4,489` frames on Worker 006 while measuring effective FPS, stage latency,
+occupancy/component growth, capacity drops and the same static anchors. The LAB
+reuses the M4.7 `VIDEO/CAMERA/3D/PLAN/SEMANTICS` viewer and projects the eleven
+anchors onto its immutable timeline; no third perception instrument exists.
+Navigation, commands, actuation, physical clearance and collision-safety
+authority remain false.
+
 ## Implementation order
 
 The implementation sequence is intentionally strict: