fix(zarr): repair an unresolvable import, and share two copy-pasted helpers

[ElmoPA]

egomimic/rldb/zarr/hdf5_to_zarr.py imported EvaHD5Extractor from
egomimic.scripts.eva_process.zarr_utils, which exists on no branch -- the class
lives in eva_utils, which the sibling eva_to_zarr.py:18 imports correctly. The
module was therefore unimportable and its CLI could not run. Predates the rename
in #562 (that commit changed no content).

safe_rot3_from_T was defined identically in robot/calibrate_utils.py and
robot/collect_demo.py. It moves to utils/pose_utils.py, next to the other pose
maths. Deliberately NOT hoisted into either robot module: calibrate_utils does a
sys.path.append + "from oculus_reader import OculusReader" at import time, so
importing it for one numpy helper would drag a VR hardware dependency into
collect_demo. pose_utils has no such deps.

The four single-arm from32 converters each re-implemented the same 10-wide block
decode, differing only in offset (left 0, right 10) and whether the gripper
channel is kept -- robot returns 7-dim, human 6-dim. The decode, including the
rotation reconstruction, moves to _decode_arm_block; each converter keeps its own
cat so the arity difference stays visible.

Verified by differential test: all four from32 are bit-identical to the previous
implementation over random inputs. (The ~pi round-trip error on random ypr is a
pre-existing _matrix_to_ypr wrap-around, identical before and after, and vanishes
for ypr in the principal range.)

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

[ElmoPA]

• fix(zarr): repair an unresolvable import, and share two copy-pasted helpers #565 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.