Harden PWM initialization failure handling

[ainyan03]

Problem

#318, #320 and #322 gave the PM1 / M5IOE1 PWM and pull APIs failure
reporting, but the board initialization paths still discard the results in a
few places where the whole point of the write is to rule out a retained
hardware state:

• On the ToughC5, when turning the buzzer PWM channel off fails, the fallback
  that reverts PM1 GPIO4 to plain GPIO mode is attempted once with its result
  ignored, while the error log claims the pin was left as a low output. If the
  fallback write also failed, a retained PWM state keeps the buzzer sounding
  despite the log saying otherwise.
• On the StopWatch, the motor is enabled as a push-pull output before the
  PWM duty-off write, and neither result is checked. If the duty-off write
  fails, a duty retained from the previous firmware drives the motor as soon
  as the pin is enabled.
• The ToughC5 CHG_PROG release (setPullMode(..., pull_none)) ignores the
  reported failure, although the comment above it states the line must stay
  released.

The PM1 PWM API also leaves its channel-to-pin mapping and the separate GPIO
function mux requirement undocumented, so a caller can get true from every
PWM call and still see no waveform on the pin.

Fix

• ToughC5: the GPIO-mode fallback is retried like the PWM-off write, and the
  log now distinguishes "switched to GPIO mode" from "could not be switched;
  silence cannot be guaranteed".
• StopWatch: the duty-off write runs first, and the pin is only enabled as an
  output once it succeeds. On failure the motor output is left disabled and
  an error is logged.
• ToughC5: a failed CHG_PROG pull release is now logged.
• The three PM1 PWM methods document that channel 0 maps to GPIO3 and
  channel 1 to GPIO4, and that setGPIOFunction() with special is needed
  separately to route the PWM to the pin.

The remaining IOExpander_Base virtuals still return void; making them
consistent is left for a separate change, as noted in #320.

[Copilot]

Pull request overview

This PR hardens board initialization paths to respect PWM / pull configuration failure reporting (especially to avoid retained PM1 / M5IOE1 hardware states persisting across ESP resets), and improves PM1 PWM API documentation so callers correctly route PWM to the intended pins.

Changes:

• ToughC5: retries the GPIO-mode fallback when PM1 PWM ch1 shutdown fails, and logs whether GPIO4 was actually switched to GPIO mode (or if silence cannot be guaranteed).
• ToughC5: logs a failure to release the CHG_PROG pull state on M5IOE1.
• StopWatch: turns off the motor PWM duty first and only enables the motor output pin after that write succeeds.
• PM1 PWM API: documents channel-to-pin mapping and the need to separately mux GPIO function to special.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/utility/power/M5PM1_Class.hpp	Adds PWM channel mapping + mux requirement notes to prevent “successful calls but no waveform” confusion.
src/utility/Power_Class.cpp	Ensures init-time PWM-off / pull writes are checked and failure handling avoids enabling outputs when safety state can’t be confirmed.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.