ReachMap.reachable_ranges persists REPORTED ticks — a re-zero silently rewrites every map

[OriNachum]

The bug

arm101/explore/reachmap.py:ReachMap.reachable_ranges persists per-joint tick ranges into the saved reachability map. Those are reported ticks — a view through each servo's homing offset at the moment of capture.

A re-zero changes the offset. Every tick in a map captured under the old calibration then names a different physical angle, with no error, no warning, and no way for a reader to tell.

Why it matters right now

elbow_flex has been re-zeroed (Ofs 85 -> 1073). Any map recorded before that is off by ~1071 ticks on that joint. And per #43, the other five joints are candidates for a re-zero too — so the blast radius is about to grow, not shrink.

The bundled default map and every run-log range are in the same frame.

The fix

Persist raw ticks. Raw is invariant under a re-zero, so a stored map cannot go stale when the arm is re-calibrated. arm101/hardware/ticks.py (landed in wave 0 of the #43 build) is the conversion boundary.

Note this supersedes the calibration-identity design proposed in the #36 spec (stamp the map with a fingerprint of the six offsets; refuse a map whose fingerprint does not match). That approach detects the staleness. Persisting raw eliminates it — there is nothing to stamp, because there is nothing that can go stale. The stamp may still be worth keeping for legacy maps written in the reported frame, which cannot be distinguished from raw ones by inspection.

Scope note

This is deliberately not #34 (the grid is derived from the wrong things). This is narrower: whatever the grid ends up being derived from, the ticks it persists must be in a frame that survives a re-calibration.

How it was found

Task t1 of the #43 build. Pinned as a known-outstanding site in _PERSISTED_TICK_SITES (tests/test_tick_frames.py), whose backlog can shrink but never grow.

Related: #43, #35, #34, #36

[OriNachum]

2026-07-13 — still live, and the blast radius is now bigger than when this was filed

arm limits (PR #48) shipped, and hardware confirms the raw-vs-reported hazard this issue names
is not hypothetical:

• elbow_flex is re-zeroed on the bench right now — its live offset is 1073, not the
  factory 85. Every REPORTED tick recorded for it before that re-zero is off by ~1071.
• Three more joints turn out to wrap the seam and are re-zero candidates (shoulder_pan
  arc 3330, gripper arc 2587 — both measured this session, see elbow_flex and wrist_roll encoders wrap — a [min, max] range cannot describe them, and gentle_move cannot converge across the seam #35). If any of them is ever
  re-zeroed, every REPORTED tick persisted for them silently becomes wrong too.

The fix direction chosen for the limits work is the one this issue should follow:
persist RAW ticks. Raw is invariant under a re-zero; reported is a view through whatever
offset happens to be in the register right now. That eliminates the staleness problem rather
than trying to detect it — no calibration identity needed. See arm101/hardware/ticks.py
(the single reported<->raw boundary) and arm101/hardware/soft_limit_store.py (which already
persists RAW) for the pattern to copy.

Related: #43 (parent), #51, #52.