1 Commits (83c965ef44bfec7dcf96e46e2dffcbb06c9b909b)

Author	SHA1	Message	Date
Strycher	4d7921d2f7	feat(#89): verify broker enable/disable actually applied before confirming ... A firmware build can ACK a broker enable/disable as success without applying it (HV4; meshcore-firmware#179). The quick toggle and the editor save previously trusted the ACK and showed a success snackbar, so an ack-but-no-op looked like it worked. Both paths now SET, wait a short settle, re-read the slot, and report what the device ACTUALLY did: - applied -> confirm - notApplied -> warn "possible firmware issue"; the editor stays and re-seeds to the device's true state instead of popping a false success - unverified -> re-read failed (e.g. an enable that rebooted the device) Every device is treated identically: the UI reflects the re-read, never assuming a change took that the device didn't confirm. - BrokerConfig.classifyApply pure classifier + BrokerApplyOutcome (unit-tested) - ObserverConfigService.applySettleDelay - wired into mqtt_brokers_screen quick toggle + broker_editor_screen save - widget test for the ACK-but-not-applied path Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 weeks ago