Web client core

[jpka]

Parent

Part of #25 (Screen Solver v1: implementation spec), itself under the map #1.

What to build

The browser page a user actually opens: it connects to the live stream, shows history, and lets them trigger a solve and pick a target window. This ticket is the client's functional core — a single reasonable layout that works correctly on a desktop browser. Orientation-aware responsive layout is deliberately deferred to the next ticket; this one just needs to be correct and usable, not yet phone-optimized.

On load, fetch GET /answers for the backlog and connect to GET /events. Render the live streaming answer (or sync{text} catch-up if joining mid-flight) alongside a history list built from the backlog plus newly completed answers. A "Solve now" button calls POST /solve. When no target window is configured, the window picker (built against ticket 2's config surface) replaces the answer pane. An interrupted answer in history is visually distinguishable from a normally completed one.

Acceptance criteria

• Opening the client with no target window configured shows the window picker, not an empty answer pane.
• Picking a window from the picker configures the target and the picker is replaced by the (initially idle) answer pane.
• Clicking "Solve now" triggers a real solve and the answer renders token-by-token as delta events arrive.
• Reloading the page mid-answer and reconnecting shows the accumulated text so far (via sync), not a blank pane waiting for the next start.
• The history list shows all previously logged answers from GET /answers, and a newly completed answer is added to it live without a page reload.
• An interrupted answer in history is visually marked as such.
• A bail (# No exercise on screen) renders in the live pane with lower visual emphasis than a normal answer.

Blocked by

#29 (Solve loop over HTTP + SSE), #31 (Answer & usage logs), and #28 (Target window config surface).