Harden SD/I2C failure paths against on-track reboots & corruption

[TheAngryRaven]

Summary

A code-quality sweep prompted by spontaneous on-track reboots (suspected failing SD card tray). The reboot itself is the 4 s hardware watchdog doing its job when SdFat blocks on a card that's physically dropping out mid-write — that can't be fully prevented in software. But four spots turned a flaky card or a glitched I2C bus into a reboot loop or silent corruption; this fixes those:

• i2cBusRecover() could boot-loop. It re-inits Wire + the OLED over I2C but never fed the watchdog (unlike the GPS baud-recovery path), so under sustained ignition EMI it could trip the WDT while recovering and re-trip on reboot. Now pets the watchdog before each blocking re-init step, and safeDisplayUpdate() recovers a hung bus inline instead of one frame late.
• Truncated DOVEX header went unnoticed. The 1 KB header pre-fill ignored each write() return, so a card dropping sectors during log creation was still marked "ready" and streamed rows into a truncated region. Now verifies every write and aborts log init cleanly (retries next second).
• Lost lap times on mid-session write failure. A failed data-row write stopped logging cleanly but never wrote the header, losing the session's lap list. Now attempts writeDovexHeader() before closing.
• buildTrackList() bypassed the SD mutex. The lone SD consumer touching SdFat raw, leaving a window where a BLE track upload/delete completing during a logging teardown could hit SdFat from two tasks. Now holds SD_ACCESS_TRACK_PARSE for the directory walk (both callers release first, so no self-deadlock) and checks the directory open.

Type of change

• Bug fix (no user-visible behavior change beyond the fix)
• New feature / behavior
• Refactor (no behavior change)
• Tests only
• CI / tooling / docs
• Breaking change (track files, log format, BLE protocol, or a removed mode)

How it was verified

• Host unit tests pass (ctest --test-dir tests/build) — pure units untouched, ran as a regression check
• clang-tidy clean — relying on CI
• Compiles for the XIAO nRF52840 Sense — relying on CI compile-sketch
• Tested on real hardware — not yet; these are failure-path changes that need a flaky-card / EMI scenario to exercise. Worth a bench test with a marginal card before relying on them.

Checklist

• CHANGELOG.md updated under [Unreleased]
• ARCHITECTURE.md / CLAUDE.md updated — no module or interface changed
• New testable logic has a matching test in tests/ — changes are Arduino/SdFat-bound failure paths, not host-testable pure logic
• Branch is focused — all four fixes are the same concern (SD/I2C failure-path hardening)

Notes

A related finding from the same sweep was left out as a separate concern: auto-race can fire while viewing replay, and live racing + replay share the same lapHistory[] buffer (stale-read hazard). Also worth wiring NRF_POWER->RESETREAS to a debug surface to distinguish watchdog resets (card stalls) from hard faults.

🤖 Generated with Claude Code

---

Generated by Claude Code

[github-actions]

Coverage — host-testable units

📂 Overall coverage

Metric	Coverage
Lines	🟢 259/260 (99.6%)
Functions	🟢 26/26 (100.0%)
Branches	🟡 237/271 (87.5%)

📄 File coverage

File	Lines	Functions	Branches
BirdsEye/crc32.cpp	🟢 30/30 (100.0%)	🟢 4/4 (100.0%)	🟢 24/24 (100.0%)
BirdsEye/dovex_header.cpp	🟢 100/101 (99.0%)	🟢 6/6 (100.0%)	🔴 61/92 (66.3%)
BirdsEye/filename_validator.cpp	🟢 14/14 (100.0%)	🟢 1/1 (100.0%)	🟢 30/30 (100.0%)
BirdsEye/gps_time.cpp	🟢 45/45 (100.0%)	🟢 6/6 (100.0%)	🟢 30/32 (93.8%)
BirdsEye/gps_validation.cpp	🟢 24/24 (100.0%)	🟢 2/2 (100.0%)	🟢 66/66 (100.0%)
BirdsEye/haversine.cpp	🟢 8/8 (100.0%)	🟢 1/1 (100.0%)	⚫ 0/0 (0.0%)
BirdsEye/lap_format.cpp	🟢 18/18 (100.0%)	🟢 1/1 (100.0%)	🟢 9/9 (100.0%)
BirdsEye/sd_access_policy.cpp	🟢 5/5 (100.0%)	🟢 2/2 (100.0%)	🟢 10/10 (100.0%)
BirdsEye/tach_filter.cpp	🟢 15/15 (100.0%)	🟢 3/3 (100.0%)	🟡 7/8 (87.5%)