feat(lidar): add point-aligned ground review

docs/adr/0020-patchworkpp-vendor-map-boundary.md

@@ -13,6 +13,20 @@ independent best-effort pose and no admitted raw sweep or scan geometry. The
 pose describes vendor odometry; it does not prove the physical height of the
 LiDAR above terrain.
 
+Static, read-only analysis of the K1 3.0.2 deployment artifacts narrows this
+boundary. K1 selects a Livox MID-360 adapter internally, consumes
+`/livox/lidar` plus `/imu`, and its point type carries XYZ, intensity,
+timestamp and ring. The configured external MQTT point-cloud sample factor is
+four, while the externally recorded `lio_pcl` is emitted after the LIO/modeling
+path. The scanner therefore measures real metric ranges and the appliance has a
+richer internal source; Mission Core has not yet admitted that internal source
+through a versioned export or bag contract.
+
+For the handheld capture, the operator measured approximately 1.27 m from the
+LiDAR head to the ground. This is useful evidence, but it is neither a
+runtime-attested extrinsic nor proof that the vendor map Z origin coincides with
+terrain. It may be used only in an explicitly marked diagnostic normalization.
+
 Treating a successful Patchwork++ call as a valid baseline would conflate API
 compatibility with input-domain compatibility. Choosing a synthetic Z
 translation until the output looks plausible would use the candidate itself to
@@ -34,7 +48,13 @@ define the normalization.
 8. Create an all-ignore, content-bound annotation template; only a separate
    human-reviewed generation may unlock ground IoU, curb/low-obstacle recall
    and reflection-noise rejection.
-9. Keep command, navigation and safety authority false.
+9. Bind sensor height, applied map vertical-origin offset and evidence class
+   (`missing`, `operator-estimated` or `runtime-calibrated`) into the immutable
+   benchmark identity.
+10. Publish one bounded, path-free point-aligned frame endpoint and render it
+    in React/Three.js with current, candidate and disagreement masks. Heavy
+    processing remains in the worker.
+11. Keep command, navigation and safety authority false.
 
 ## Consequences
 
@@ -45,6 +65,11 @@ define the normalization.
   threshold tuning around a mis-specified sensor model.
 - The same immutable benchmark/API/React surface can compare a future raw scan,
   replay or simulation provider without moving C++ processing into React.
+- Firmware evidence justifies implementing an admitted onboard raw
+  point/IMU exporter or bag reader; it does not retroactively upgrade existing
+  MQTT recordings to raw scans.
+- The 1.27 m run makes the effect of the operator estimate visible and
+  repeatable, but remains diagnostic-only.
 
 ## Real diagnostic evidence
 
@@ -60,10 +85,26 @@ processed 66 frames and 226,963 points:
 Algorithm ground IoU was 2.90% p50 and point disagreement was 17.92% p50.
 Neither is an accuracy metric. Independent labels are still missing.
 
+The explicit operator-height variant
+`ground-benchmark-87cb3150701f7e21756f46ef5b6ce110df1e07720ef6dc2303c95520932cf43f`
+applied a 1.27 m map-Z offset and processed the same 66 frames and 226,963
+points:
+
+| Measurement | Current local percentile | Patchwork++ |
+| --- | ---: | ---: |
+| Ground fraction p50 | 18.31% | 2.47% |
+| Host latency p95 | 11.85 ms | 0.42 ms |
+
+Algorithm ground IoU was 4.07% p50 and point disagreement was 19.13% p50.
+This is evidence that height/origin normalization materially changes the
+candidate result, not evidence that either algorithm is accurate.
+
 ## References
 
 - `src/k1link/compute/lidar_ground.py`
 - `experiments/perception/run_lidar_ground_benchmark.py`
 - `src/k1link/web/lidar_api.py`
 - `apps/control-station/src/workspaces/LidarQualityWorkspace.tsx`
+- `apps/control-station/src/workspaces/LidarGroundPointCloud.tsx`
+- `docs/lab/005_K1_FW302_LIDAR_PIPELINE_20260725.redacted.md`
 - `docs/13_LIDAR_WORKER_PRODUCT_AND_ROADMAP.md`