fix(esp): route daily noon capture through the restart cold-start

[cofade]

Summary

Issue #143: a field module uploaded near-black images at its daily noon capture, while a power-cycle restart always produced a good image. This routes the noon capture through the same proven-good camera cold-start the boot/restart path uses.

This is a mitigation, not a confirmed fix — #143 stays open (see "Honesty" below).

What the bench investigation found (and ruled out)

Reproduced both capture paths on a healthy bench module (hive-02, COM9) against a local stack and compared cold vs warm frames directly:

variable tested	idle	cold-grab result
missing warm-up (UXGA / PSRAM path)	20–160s	exposes fine — identical to warm
missing warm-up + forced VGA/internal-DRAM (the field config)	20–40s	exposes fine — identical to warm

So the issue's leading hypothesis ("noon skips the warm-up") is disproven on healthy hardware — its candidate fix would have changed nothing. The affected board's "PSRAM not found" is itself a hardware-fault symptom (with reset_reason=7 watchdog + flash read err, and variable black severity), so the root cause is most likely that board's marginal hardware, which a healthy bench board cannot emulate by flipping a code path. Full writeup: the chapter-11 lesson in this PR + the issue comment.

The change

• primeCameraLikeBoot() (ESP32-CAM/ESP32-CAM.ino): PWDN power-cycle + reinit + 3-frame warm-up before the noon grab — the restart cold-start.
• New non-aborting recoverCameraSoft() (esp_init.cpp): the noon re-prime must never abort() from steady-state — on a marginal board that would risk a daily panic → reboot → (after 3) firmware rollback. The boot path keeps initEspCamera()'s abort() (load-bearing for OTA rollback), gated by a new abortOnFailure param (default true, so every existing caller is unchanged).
• Fail-safe: a reinit failure or an all-NULL warm-up skips that day's capture and retries next loop; lastCaptureDay is set only when prime and upload both succeed (mirrors the first-capture-on-boot gate).

Honesty: this is an unvalidated mitigation

The bench could not reproduce the failure on healthy hardware, so the fix could not be confirmed. The code comments and docs say so explicitly. It routes the daily image through the one path observed to always work, which is robust regardless of the (likely hardware) mechanism — but it intentionally leaves #143 open until the on-b0696 test settles the root cause.

Out of scope / follow-up

• The separate "modules show offline" symptom found in the same session (old mason firmware geo-TLS waste + two loop() hardening gaps) is tracked in ESP firmware: harden against silent offline (WiFi-health reboot fallback + heartbeat retry) #149.

Testing

Done:

• pio run -e esp32cam builds clean.
• Native/unit suites unaffected (firmware-only change; no lib/ helper touched).
• Bench-flashed a real module (longhorn + a throwaway diagnostic) and confirmed the boot / cold / warm capture paths upload to a local stack; compared frames directly (the table above).
• Three rounds of senior-reviewer; the non-aborting design + warm-up-NULL gate are the result.

Could NOT do — needs the affected board (b0696ef23a08, or any "PSRAM not found" board) on USB:

• Validate the fix against the actual failure. Plan:
  1. $env:DEV_SERVER_HOST="192.168.178.49" (your dev-box LAN IP); pio run -d ESP32-CAM -e esp32cam -t upload --upload-port COM9 — or flash via the web installer.
  2. python scripts/esp_capture.py COM9 90 — confirm -- priming camera (restart-equivalent cold-start), the loop:primeCamera:noon breadcrumb, and non-NULL prime warm-up frame N OK (… bytes) lines.
  3. Trigger a real noon capture (or temporarily change tm_hour == 12 to the current hour, or set the device clock) and confirm the uploaded noon frame is well-exposed, not near-black.
  4. Regression: confirm a healthy module still captures normally at boot and noon.

🤖 Generated with Claude Code