StopWatch: recover ES8311 capture after power-on reset

[ainyan03]

Fixes #347 (StopWatch: microphone returns all-zero samples once M5.Speaker.begin() has run).

Root cause (measured on StopWatch hardware, arduino-esp32 2.x and 3.x)

The ES8311 arms its capture path only through a SYSTEM(0x0D) write performed while the I2S bus clock is running. A write issued before the clock starts is absorbed silently: it is acknowledged and even reads back, but has no effect. The microphone enable callback runs before the capture task starts the I2S clock, so on the StopWatch the capture path was never armed and every recording came back as zeros.

Two more measured properties shape the fix:

• The arming is needed once per codec power-on reset and survives I2C power-down/up cycles (Mic.end()/begin()).
• The previous Speaker.end() path cut the codec power rail (M5IOE1_G3), so every speaker→mic transition forced a fresh reset — this is why the issue reproduces exactly after M5.Speaker.begin() has run. A quickly cycled rail also produces marginal resets that make the recovery unreliable.

Fix

1. Mic_Class: post-start callback + lifecycle serialization — begin() can now invoke a (private, M5Unified-only) callback once the capture task has enabled the I2S channel, in the caller's context. A missing clock or a failed callback tears the port down and fails begin(). While touching this path, begin()/end() are serialized under _begin_lock (a concurrent end() could previously interleave with a begin() in progress), and a failed enable callback or I2S setup now rolls back via the disable callback and driver uninstall.
2. StopWatch: ES8311 capture recovery — the post-start callback writes 0x0D=0x01 at roughly +30/+60/+90 ms after the clock start (earliest working point measured ~+25 ms) and latches the armed state, so only the first Mic.begin() after a codec reset blocks, for about 100 ms; later ones are unaffected. A reset performed outside the library (rail cycled by the application, brown-out) is detected through register 0x17 and re-arms. Speaker.end() now keeps the rail on and powers the DAC down over I2C, so alternating speaker/mic use no longer resets the codec each time.

Behavior notes

• After the arming, the ES8311's analog stage still warms up on its own for roughly one second after the codec powered up; during that window captured samples can be all zero. This is chip physics — neither blocking nor extra writes shorten it — so begin() documents it instead of hiding it behind a long block. An application that records immediately after the very first begin() will see one quiet capture; everything afterwards is normal.
• Speaker.end() no longer cuts the codec power rail on the StopWatch (DAC is powered down over I2C instead). This slightly changes idle power draw after Speaker.end() in exchange for reliable and fast speaker/mic transitions; please review this trade-off from the product side.
• ChainCaptain uses the same callback structure and the same codec and most likely needs the same treatment, but I could not verify it on hardware, so it is left unchanged here.

Verification

On a StopWatch unit, with both espressif32 6.12.0 (arduino-esp32 2.x, as in the report) and pioarduino (arduino-esp32 3.x), across 10+ cold boots each:

• cold boot → Mic.begin() → record: real samples (previously all-zero)
• the reported path Speaker.begin() → tone → Speaker.end() → mic: real samples
• repeated speaker↔mic alternation: stable
• manual codec power-rail cycling: detected via the 0x17 witness and re-armed
• M5.Speaker/M5.Mic behavior on other boards is unchanged (the callback is registered only for the StopWatch); compile-checked for ESP32/ESP32-S3/ESP32-C6 on both core generations, and the stock Basic/Microphone example was verified on the StopWatch display

A machine-readable readiness query (e.g. Mic.isReady() for the warm-up window) could be a follow-up if desired.