CoreS3: fix external 5V output not turning off / re-enable being cancelled on USB-C without battery

[ainyan03]

Problem

On CoreS3 / CoreS3 SE, setExtOutput(false) wrote BUS_OUT_EN (AW9523 P0_1) and BOOST_EN (P1_7) in a single two-byte transaction, so BUS_OUT_EN dropped before the boost converter stopped. BUS_OUT_EN=0 turns the BUS input-side switch (U19) on; when the bus is still at 5V at that moment, the switch never enters reverse-current blocking and USB VBUS keeps feeding BUS_OUT. The visible symptoms:

• Port A / M-Bus 5V stays on after setExtOutput(false).
• Without a battery, the TS reading (a 1:1 divider of BUS_OUT) stays above 2.0V, so every later setExtOutput(true) is cancelled with setExtPower(true) is canceled. until the device is power-cycled. This is the recovery-impossible path behind Documentation: CoreS3 Requires Battery for Grove/MBUS Power When USB Powered M5CoreS3#72 (USB-C only, no battery).

Fix

• When BUS_OUT_EN goes 1→0: write BOOST_EN=0 first, wait 200 ms for the bus to discharge, re-read the expander and clear only the requested bit. If any I2C transfer fails, re-read the latch and recover from the actual state (restore BOOST_EN to its initial value while BUS_OUT_EN is still set, or leave BOOST_EN off once BUS_OUT_EN has dropped; if the latch cannot be read, write back the initial pair).
• Other paths (enable, USB OTG) no longer use a single two-byte write that can be applied partially: bits are written one register at a time, BOOST_EN before the output enable when turning on and after it when turning off, stopping if the first write fails.
• Serialize every AW9523 output-port writer inside M5Unified (setExtOutput, setUsbOutput, Power_Class::begin, the CoreS3 speaker amplifier enable) with one mutex, and run the no-battery protection check inside the same critical section so a concurrent disable cannot invalidate the check.
• Protection check (no battery + VBUS + TS above 2.0 V): skip it when BUS_OUT_EN is already 1 (the 5 V on TS is our own output; this also removes the spurious warning on warm reset with output_power=true). It reads the raw registers and treats an I2C read failure or an invalid ADC value as unsafe (fail closed). When it reads unsafe it releases the lock, waits 20 ms and re-checks for up to 1 s, because the TS ADC lags the real voltage by several hundred ms and would otherwise cancel a re-enable issued right after a disable; external bus power keeps TS high, so the protection still cancels in that case. Requests carry a generation number so an enable that is still waiting yields to a later disable.

Measured discharge boundary on a CoreS3 (no battery, USB-C): 10 ms fails / 20 ms works with a Grove unit attached, 70 ms fails / 80 ms works with no load. 200 ms leaves margin.

Notes

• On the CoreS3 family setExtOutput(false) now blocks for about 200 ms when the output was enabled, and setExtOutput(true) without a battery may block for up to 1 s while the protection check waits for TS to settle (both documented in the header).
• The pre-existing fail-open window (external 5V applied to Port A and setExtOutput(true) called before the TS ADC has caught up) is unchanged by this PR.
• The mutex covers M5Unified only. The display driver's panel reset also read-modify-writes the same expander port outside it; that race predates this PR and is unchanged.
• Verified on CoreS3 (no battery, USB-C) with and without a Grove unit attached.