perf(sensors): publish coherent barometer snapshots

[zjwhitehead]

Decision

Keep this draft until the live ESC/BMS acceptance matrix below passes. Merge #125 first, then rebase this branch and rerun the combined smoke test because both touch the controller-sensor task context.

What changes

• add one low-priority, core-1 BMP3xx producer at 25 Hz
• replace independent altitude, pressure, and temperature reads with one coherent BarometerSnapshot
• protect the 29-byte cross-core snapshot with a short port critical section; no reader takes the I2C mutex
• make the 10 Hz telemetry producer consume one snapshot rather than five loose globals
• zero AGL from a cached sample and reject arming when the sample is missing or older than 250 ms
• drop overrun UI and barometer slots while retaining the original scheduler phase
• correct the BMS task comment from 20 Hz to its actual 10 Hz cadence

Why

The prior P3 experiment wrote independent float globals. The writer-side I2C mutex did not make those fields coherent for readers. This version publishes all derived values, sample time, and validity together.

The previous missed-frame policy also reset lastWake to now. With a measured 37 ms render and a 33 ms period, that schedules the next frame at 70 ms. The phase-aligned policy advances the base to 33 ms and schedules the next frame at 66 ms. It prevents catch-up bursts without converting cadence into render time plus period. Getting render time below 33 ms remains the separate path to approximately 30 FPS.

Local validation

• ESP32-S3 production target build: PASS
  • RAM: 120,464 / 327,680 bytes
  • flash: 1,210,909 / 3,342,336 bytes
• native tests: 64/64 PASS
  • includes 37 ms versus 33 ms phase behavior, multi-slot drops, and tick rollover
• screenshot regression tests: 34/34 PASS
• cpplint: PASS

Live hardware acceptance matrix

Controller and barometer

• cold-boot 10 times; no Baro_Init_Failure after the existing retry sequence
• confirm pressure, temperature, altitude, and vertical speed update together with no mixed or impossible samples
• wait at least 10 seconds, arm at zero throttle, and confirm displayed AGL becomes 0.0 without a forced I2C conversion
• disconnect or stall the BMP path and confirm arming is rejected with Arm blocked: no fresh barometer sample
• verify repeated arm, disarm, and re-arm after the 500 ms cooldown

Real ESC

• begin with propeller removed and throttle at zero
• verify arm, throttle ramp, cruise entry and exit, and disarm preserve the 50 Hz control loop
• confirm an arm rejection never changes device state or emits non-idle throttle
• exercise ESC link loss and recovery in both disarmed and armed-safe bench states
• verify ESC config and firmware relay interlocks still block arming

Real BMS and battery

• cold-connect and hot-plug the BMS; CONNECTED must appear only after pack and cell frames form a coherent snapshot
• verify voltage, current, SOC, cell extrema, temperatures, and alert transitions
• run heavy display redraw while BMS CAN, BLE notifications, and barometer sampling are active; no starvation, stale barometer arm gate, or SPI mutex timeout trend
• disconnect and reconnect BMS and verify fallback to ESC battery telemetry and recovery

Soak and lifecycle

• 30-minute all-peripheral soak while collecting reset diagnostics, minimum heap, task stack watermarks, CAN errors, link state, and UI cadence
• perform BLE OTA, reboot, and one post-OTA arm/disarm cycle
• acceptance: no watchdog reset, assert, tsens error, deadlock, control-loop miss, unexpected arm rejection, or new alert regression

Not included

• no performance instrumentation or generated sdkconfig changes
• no display or MCP2515 transport rewrite from P5
• no CPU-temperature ownership changes from fix(sensors): make CPU temperature single-writer #125