Fix charging wake radio startup

[ODevStudio]

Summary

• enable BLE/WiFi startup when a user wakes the scale from charging UI with O or square
• keep passive USB charging quiet until a button wake occurs
• add a small source contract test for the charging wake path

Validation

• python tools/test_charging_wake_contract.py
• git diff --check
• pio run -e esp32s3
• flashed to COM, confirmed charging wake re-enables radios

[tadelv]

Approve. No WiFi.setSleep(false) introduced (coexistence footgun #2 not tripped). Button wake runs on the loop task, so ble_init() / wifi_init() are safe to call there. The if (!b_ble_enabled) / if (!b_wifiEnabled) guards are a real improvement — the old path called ble_init() unconditionally on every charging wake, and ble_init() is not idempotent (BLEDevice::init without de-init). Cross-task flags used in the guards are already volatile.

Minor (non-blocking):

• b_is_charging = false in wakeFromChargingUi is misleading dead code — the USB cable is still connected, so the device is still charging. The loop re-asserts b_is_charging = true next pass anyway, and power_off(-1) in the button wrapper ran against the pre-clear value, so no functional bug, but the line reads wrong. Either drop it or mirror the real condition (digitalRead(USB_DET/BATTERY_CHARGING) == HIGH).
• The contract test doesn't pin the guard clauses it's meant to protect — a refactor that drops if (!b_ble_enabled) / if (!b_wifiEnabled) still passes. Add assertions for those.
• PR body slightly overstates WiFi coverage: wifi_init() early-returns on !b_wifiOnBoot, so WiFi starts on charging wake only if the user opted into WiFi-on-boot in the menu. Code is consistent with boot behavior; only the description overstates it.

Suggestion (separate from this PR): same testing note as #81/#83 — the contract test is static string-matching. Moving the wake/init logic into a pure host-compilable unit with real unit tests would catch the guard-drop regression the current test can't.