Voice wake exit is lost after WebSocket reconnect in sticky states

[BrettKinny]

This was generated by AI during triage.

Problem

receiveAudioHandle.startToChat gates wake phrases using conn.current_state, which defaults to idle on a new WebSocket connection and is populated only by live state_changed events. If the socket reconnects while firmware remains in sleep, security, or story_time, no authoritative state snapshot is replayed. A correctly transcribed "wake up" is then treated as ordinary conversation and never dispatches self.robot.set_state({state: "idle"}).

This is separate from UAT US7: in the filmed run Whisper transcribed the likely wake command as Welcome, so the wake router never ran before the later reconnect.

Desired behavior

A new connection should learn the device's authoritative sticky state before wake-phrase routing. After reconnecting in a non-conversational state, "wake up" should dispatch exactly one transition to idle.

Acceptance criteria

• A deterministic handler/integration test creates a fresh connection while authoritative device state is security, feeds wake up, and observes exactly one set_state(idle) dispatch.
• The same state restoration works for sleep and story_time.
• Reconnecting while already idle does not make ordinary uses of "wake up" force a redundant transition.
• Bench verification: enter security, reconnect WebSocket without changing device state, say "wake up," and observe wake-router log, state_changed -> idle, security cancellation, and physical scan stop.

Scope boundary

Do not add Welcome as an ASR alias for wake up; it is a common word and would create false state exits. The fix should restore/synchronize state, not route wake phrases unconditionally.