Fix IMU process memory leak + CPU spin (and guard contrast-reserve log spam)

[brickbots]

Summary

Two fixes found by the real-hardware endurance test that followed #470. #470 fixed the comet CPU hog; this PR fixes a second, distinct failure mode the endurance test then surfaced — and that mode (a memory leak) is the more likely driver of the actual OOM/freeze. See Relationship to #470 below.

1. IMU process memory leak + CPU spin (primary)

The imu_monitor loop (imu_pi.py) had no sleep. imu.update() throttles the I²C reads to 30 Hz, but the loop body still ran thousands/sec, calling shared_state.set_imu() every iteration. set_imu crosses a multiprocessing Manager proxy, so each call pickles the ImuSample — and pickling a numpy.quaternion leaks (~25 MB/200k dumps, numpy-quaternion 2023.0.4). On real hardware the IMU child leaked ~16 MB/min and spun ~19 % CPU; on a 2 GB Pi that exhausts RAM → swap-thrash → OOM/freeze. Invisible to the fake-IMU headless harness (its update() self-throttles with sleep(0.1)), which is why earlier headless profiling never caught it.

• Throttle the loop to the sample rate — sleep only the remainder of the period (period − work), so publishing tracks 30 Hz instead of drifting to period + work. The > 0 guard keeps the fake-IMU fallback from double-sleeping. 19 % → ~2.4 % CPU.
• Stop pickling the quaternion — __getstate__/__setstate__ on ImuSample.quat, PointingEstimate.imu_anchor, and SuccessfulSolve.imu_anchor (the same quaternion also rides set_solution's deepcopy + solver_queue). Pickles 4 plain floats, rebuilt on unpickle; the in-process attribute stays a real numpy.quaternion, so consumers are unchanged.

2. Contrast-reserve log spam (rider)

pydeepskylog.contrast_reserve() logs logger.error(...) and returns (doesn't raise) when an object diameter is None, so the surrounding except can't suppress it. object_details calls it per redraw with diameter=None for sizeless objects → steady ERROR-level spam that bypasses the root=ERROR filter. Guard: skip the call when a diameter is None (same blank-contrast result, minus the error).

Verification

• A/B pickle.dumps RSS: bare quaternion +24.8 MB/200k; all three patched dataclasses +0.0 MB.
• Unit/smoke: 440 pass (incl. new ImuSample / None-anchor round-trip tests in TestPicklability); ruff + mypy clean; test_ui_modules 211 pass.
• 50-min real-hardware endurance (real BNO055, Test Mode, IMU child watched directly): anonymous heap flat 113.8 → 113.8 MB (slope −0.000 MB/min), CPU mean 2.35 %, RSS +6.4 MB one-time COW step then plateau. Prior baseline: 134 → 545 MB / 19 % in 28 min.

Relationship to #470

#470 ("Vectorize comet propagation") fixed the CPU hog — calc_comets pegging a core whenever locked. That is a real pathology (UI starvation, heat), but a CPU hog alone doesn't typically hard-crash the OS. This PR fixes a memory leak that does: ~16 MB/min on a 2 GB Pi exhausts RAM in well under an hour → swap-death / OOM, which presents as the field "hang." The endurance test that found this leak ran after the comet fix, with the hog already gone — so the two are independent.

Best current understanding: the field freeze was primarily this memory leak, with the comet CPU hog a compounding factor. Both fixes are needed for a healthy long observing session. #470's description has been updated to match.

🤖 Generated with Claude Code