fix(ws): remove periodic status broadcast; align push pattern with BT

[skialpine]

Summary

The /snapshot WebSocket was the only protocol pushing periodic state snapshots. BT notifies only weight + on-event; USB binary follows the same shape. WiFi did a periodic type:\"status\" frame every 5 s when events_enabled — for state that nothing on-device consumed and that was the dominant heap-pressure source in PR #61's 8 h soak.

After this PR, clients get state on demand via {\"command\":\"status\"} — same model as BT's 0x22 voltage request, same per-client reply path that already exists. No protocol field is removed; the status frame shape is unchanged, it's just no longer pushed automatically.

Why

• No consumers: the on-device web apps (web_apps/{Quality_Control_Assistant,Weigh_Save,dosing_assistant,index.html}) have zero references to battery_percent, timer_seconds, charging, low_power, etc. Grepped. Verified.
• Heap pressure: in the 8 h soak that motivated fix: tighten WS heap defenses (cap=4, broadcast floor 32K) #61, status broadcasts were generating ~5,000 OOM-gate skip events under marginal RSSI. Removing the periodic push removes the largest WiFi-only allocation pattern.
• Cross-protocol consistency: BT clients ask for battery; WiFi clients had it pushed. Now both ask. Easier-to-write apps that work the same regardless of transport.

What's preserved

• sendWebsocketStatus(client, ...) — per-client reply to {\"command\":\"status\"} / battery / info. Unchanged.
• sendWebsocketButton, sendWebsocketPowerOff — event-driven broadcasts. Still gated on b_websocketEventsEnabled. Unchanged.
• Status frame shape (16 fields including protocol_version, firmware_version, battery, timer state, etc.). Unchanged.
• The default-2Hz weight stream, rate negotiation, all WS commands. Unchanged.

What's removed

• sendWebsocketStatusAll() function (no callers after this PR)
• The periodic-tick block in loop() that called it every 5 s
• t_lastWebsocketStatusUpdate global (no period timer to track)
• WEBSOCKET_STATUS_NOTIFY_INTERVAL_MS constant
• WS event handler no longer initialises/resets the period timer
• README sentence claiming periodic status; "events on" paragraph updated

Backward compat

The events on command still works and still controls button + power-off event broadcasts. Clients that were relying on the 5 s periodic status push need to poll {\"command\":\"status\"} themselves (any cadence they want). Existing clients that ignore status frames they didn't ask for are unaffected.

Test plan

• Build clean (pio run -e esp32s3) — RAM 16.8%, Flash 45.5%
• Hardware smoke test: 20 s window after events on + rate 10k → 201 weight frames at 10 Hz, 0 status frames (would have caught 4 periodic status frames if leaking)
• On-request {\"command\":\"status\"} still answers with the full 16-field frame
• Verify decentespresso app and on-device web UI still work (no consumers, low risk)

🤖 Generated with Claude Code

[skialpine]

Code review

Found 3 issues in cb569d3, all addressed in 7c3b004:

1. Heap-gate doc comment in include/websocket.h still claimed "Skipping a frame is invisible (the next weight frame is <=500 ms away, status <=5 s); crashing is not." This PR removes the only periodic status broadcaster (sendWebsocketStatusAll), so the "status <=5 s" recovery guarantee no longer holds. Misleads future readers about what the gate actually protects.

https://github.com/decentespresso/openscale/blob/cb569d3b6c20d4cd1da3acb5fe9ffdaa6f4ea29f/include/websocket.h#L164-L172

2. The multi-line "Broadcast via printfAll()..." preamble was originally written to introduce sendWebsocketStatusAll. After deletion it sits above sendWebsocketWeightAll with an appended "Note: status is no longer broadcast periodically..." paragraph. The technical claims (mutex, no availableForWriteAll, setCloseClientOnQueueFull) still apply to weight broadcasts, but the historical framing reads oddly. Dropped the addendum so the comment reads as native documentation for sendWebsocketWeightAll.

https://github.com/decentespresso/openscale/blob/cb569d3b6c20d4cd1da3acb5fe9ffdaa6f4ea29f/include/websocket.h#L242-L256

3. (pre-existing, CLAUDE.md Missing files so_boot_menu.h and so_wifi_ota.h #1 footgun) sendWebsocketStatus is invoked from handleWebsocketControlCommand on the AsyncTCP task and reads stopWatch.isRunning() / stopWatch.elapsed() directly. CLAUDE.md threading model: "stopWatch.* -- No -- multi-field (running flag + start ts + accumulator) and also mutated from loop(), BLE and USB; a status-frame read can tear a write across tasks". After removing the periodic broadcast this is now the sole path that reads stopWatch from the WS side, so the tear window matters more. Mirrored PR Scale telemetry: SoC temp, weight-stall watchdog, reset reason #57's g_timerRunning/g_timerElapsed snapshot pattern (refreshed once per main-loop pass; status frame reads snapshots).

https://github.com/decentespresso/openscale/blob/cb569d3b6c20d4cd1da3acb5fe9ffdaa6f4ea29f/include/websocket.h#L222-L228

Note: PR #57 adds the same g_timer* snapshot independently. Whichever lands second produces a trivial same-lines conflict that git auto-resolves.

---

1 below-threshold issue (50-74)

• [OK to skip] Comment at include/websocket.h:243-246 says "BT has no periodic state push" — technically accurate for state (battery/gyro/voltage are request-only on BT) but could be misread as "BT is entirely request-driven", which is false (weight + button + power_off are pushed). Wording suggestion, no behavior implication (score: 25 — actually below the report threshold but worth a glance if you're in this area).

Verified on hardware after the fix commit: 12 s window with events on + rate 10k → 121 weight frames, 0 periodic status frames; on-request {\"command\":\"status\"} returns the full frame with timer_running/timer_seconds populated from the snapshot.

🤖 Generated with Claude Code

_{If this code review was useful, please react with 👍. Otherwise, react with 👎.}