Spike: prototype the Playground press→feedback loop

[jonocodes]

Prototype spike: does the press→feedback loop feel alive?

Throwaway spike to de-risk the whole mocked-demo epic before we build the foundation properly.

Question to answer

When a user presses a deck button in a backend-free browser session, and a fake in-browser "app" reacts (music position advances, a value moves), does it feel alive enough to be worth building out?

Minimal build

• A MockDaemon stand-in that satisfies the same surface useDeckdSocket produces (a send() + a way to push ServerMessages into the existing callbacks: onLayout, onMediaState, etc.).
• One ticking virtual music app: holds position, advances on a clock, emits media_state + chrome_media, responds to media_command (pause actually pauses the progress bar).
• Wire it behind the existing ?demo= path so no real WebSocket is involved.

Success = gate for the epic

• Pressing play/pause on the deck visibly moves/stops the progress bar.
• It feels like "using the app," not a static mock.
• We have a clear read on whether the MockDaemon seam against useDeckdSocket is as clean as the plan assumes.

Throwaway code is fine — the goal is the judgment call, not shippable quality.

Part of the mocked-demo epic.

[jonocodes]

Tracked under epic #157.

[jonocodes]

Spike complete — gate passed. MockDaemon in client/src/playground/ speaks the real wire protocol into the useDeckdSocket callback surface; App branches on ?playground. One ticking virtual music app. Browser-verified: position advanced while playing, froze on pause, transport works — all through the real MediaCell/media-store, no backend. Seam is ~2 files + a 3-line branch in App.tsx. Ready to close once reviewed. See epic #157 for the full write-up + the VLC-art-fallback finding.