docs(perception): record m4 geometry acceptance

docs/22_MILESTONE_4_OBJECT_CENTRIC_RECORDED_REALTIME_CV.md

@@ -2,7 +2,7 @@
 
 Date: 2026-08-05
 
-Status: in progress; M4.0–M4.3 accepted, M4.4 geometry/range is next
+Status: in progress; M4.0–M4.4 accepted, M4.5 temporal/motion is next
 
 Audit base: `1b3e0b3` on `feat/simulation-polygon-s1`
 
@@ -794,6 +794,59 @@ and healthy Triton
 retained their exact identities; no public port, cutover or Platform dependency
 was introduced. M4.3 is closed and M4.4 geometry/range may start.
 
+### 2026-08-05 — M4.4 canonical geometry/range acceptance
+
+The accepted E29/E32 mathematics was extracted into the product-owned
+`k1link.perception.geometry_math` module. The runtime provider imports neither
+the eager legacy `k1link.compute` package nor device-plugin initialization.
+Numerical parity of KB4 projection is tested against the accepted historical
+primitive on the sealed RAVNOVES00 source pack. The versioned profile
+`config/perception/m4-geometry-association-v1.json` binds the exact source pack,
+local-surface model, projection and association thresholds by SHA-256.
+
+`Ravnoves00GeometryAssociationProvider` now enforces the product contract:
+
+- range is published only with exact current frame-local source-point IDs;
+- overlapping camera claims use deterministic smallest-box, score and proposal
+  identity arbitration;
+- a claim that loses all points remains camera-only with unavailable range;
+- source-unavailable, local-surface-unavailable, outside-overlap, sparse,
+  conflict and ownership-collision outcomes remain distinct;
+- unclaimed current occupied components are published without semantic class;
+- total and eligible range coverage use separate denominators;
+- missing points never create free-space evidence or physical authority.
+
+The provider consumed the immutable M4.3 Worker 006 proposal ledger and sealed a
+fresh full-source local Mission Core replay:
+
+- result ID:
+  `m4-geometry-replay-8daf3109e3cf30b960b4b376032ff3b5ec58ca42a1e5899b841cf29fbcf14ad8`;
+- frame ledger SHA-256:
+  `b4db5d0ebaba4d6268a1006707dc313c229f3dbdfd73b1d863cad5d853be8ac4`;
+- `4,489 / 4,489` frames, `0` failed;
+- exact source accounting: `3,928` LiDAR-available and `561` unavailable
+  frames, matching accepted E32 and E53;
+- `15,499` detector proposals: `5,341` with current metric range, `10,071`
+  camera-only and `87` explicit conflicts;
+- `13,298` proposals were eligible for range; total coverage is `34.4603%`
+  and eligible coverage is `40.1639%`;
+- camera-only reasons include `2,044` source-unavailable, `157`
+  outside-overlap, `7,724` sparse and `146` ownership-collision cases;
+- `21,958` independent geometry-only occupied observations, all classless;
+- `2,164,767` exclusively owned source-point rows and `4,482` overlapping
+  claims removed;
+- local provider latency p50 `2.733 ms`, p95 `3.693 ms`, max `16.872 ms`.
+
+An independent second execution produced the same frame-ledger SHA-256. Runtime
+latency remains a separate report metric and cannot perturb the canonical
+observation bytes.
+
+All ten M4.4 acceptance requirements in the immutable result are true. This is
+algorithmic and contract acceptance on the recorded source, not a physical-live
+claim and not a Worker 006 cutover. No class name participates in association or
+range. M4.4 is closed; M4.5 temporal retention and class-independent motion is
+the next implementation phase.
+
 ## Implementation order
 
 The implementation sequence is intentionally strict: