fix(sensing-server): route WS source through effective_source() (closes #618)

[ArnonEnbar]

Closes #618.

Summary

The two WebSocket broadcast sites in the sensing-server tick loop hardcoded source: "esp32".to_string(), bypassing the existing AppStateInner::effective_source() stale-detection logic. As a result, the UI continued to show "LIVE — ESP32 HARDWARE Connected" with frozen cached values for arbitrarily long after the ESP32 lost power or WiFi.

This PR replaces both literals with s.effective_source() so the WS path emits "esp32:offline" once ESP32_OFFLINE_TIMEOUT (5 s) elapses, matching the behaviour the REST /health endpoint already had.

Diff

-                        source: "esp32".to_string(),
+                        source: s.effective_source(),

Applied at the two existing call sites in v2/crates/wifi-densepose-sensing-server/src/main.rs. The s AppStateInner mutable guard is already held at both points (acquired upstream as let mut s = state.write().await;), so no new locks or restructure is needed.

Diagrams

Before — bug

WS broadcast loop emits hardcoded source: "esp32" every 100 ms tick, regardless of UDP frame freshness. UI cannot distinguish live vs cached state.

After — fix

WS broadcast now routes through effective_source(), which returns "esp32:offline" when last_esp32_frame.elapsed() > ESP32_OFFLINE_TIMEOUT. UI can flip to a degraded-state indicator.

Source .drawio file is included for future editing: docs/diagrams/issue-618/source-stale-detection.drawio.

Why this matters

The project markets fall-detection, vital-sign monitoring, and overnight apnea screening use-cases. Silent stale-as-live is a safety-critical failure mode — a deployed system whose ESP32 lost power could continue reporting "present, breathing normal" indefinitely, masking a real emergency. The 5 s offline timeout was clearly designed to prevent exactly this, but only covered REST consumers.

Test plan

• Build with cargo build -p wifi-densepose-sensing-server --no-default-features (clean, 1 pre-existing unused-imports warning)

• Manual repro per WebSocket sensing broadcast hardcodes source="esp32", bypasses 5s stale-detection (effective_source not called) #618: ESP32 unplugged → after 5 s, /health reports esp32:offline AND now WS /ws/sensing payload source also flips to esp32:offline.

• No unit/integration test added. effective_source() is a single if chain, the diff is literal-to-method swap. Adding a test would require either:

  • extracting a pure helper from effective_source() (refactor outside this PR's scope), or
  • constructing a full AppStateInner with all ~80 fields (no Default impl).

  Happy to add either approach if a reviewer prefers — let me know which direction. Otherwise, the manual reproduction in WebSocket sensing broadcast hardcodes source="esp32", bypasses 5s stale-detection (effective_source not called) #618 is the verification.

Build notes

Compiled on Windows with stable-x86_64-pc-windows-gnu (project default rust-toolchain.toml pins MSVC; switched locally via rustup override because MSVC build tools weren't installed). Fix is pure-Rust and target-agnostic, so this shouldn't matter for CI.

Wider scope (not addressed here)

This fix lets the UI know the data is stale; it does not prevent the WS broadcast loop from continuing to emit the cached frame each tick. A more thorough fix could:

• Suppress WS broadcasts when effective_source().ends_with(":offline"), or
• Add a stale: bool field on SensingUpdate (precedent: per-node NodeFeatureSnapshot.stale at main.rs:478).

Kept this PR minimal so it can land independently; happy to follow up.