Solve loop over HTTP + SSE

[jpka]

Parent

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

What to build

The end-to-end "solve now" behavior over HTTP, wiring the capture session and the provider seam together and broadcasting the result live. This is the tracer bullet for the whole app — after this ticket, a raw HTTP client can trigger a real solve against a real target window and watch it stream.

POST /solve performs only synchronous validation (is a target window configured) — 400 if not, 202 on accept, 503 if the server itself isn't ready. It always interrupts whatever solve is currently in flight; there is no busy rejection. Before spending a call, it runs the pre-flight guards from ticket 3's exposed signals (window gone/unresolvable, minimized/off-desktop, black/zero-size frame) — a failing guard is a silent no-spend with no SSE event. Once a call is actually attempted, GET /events (Server-Sent Events, one shared broadcast, no per-client filtering, no auth) emits start, then delta{text} as the provider streams, then a terminal done{usage} or error{kind}. The server holds the in-flight accumulated text in memory. Interrupting a solve in progress ends its stream as interrupted for downstream consumers (ticket 6 persists this; this ticket only needs to produce the signal).

Acceptance criteria

• POST /solve with no target window configured returns 400 and produces no SSE traffic.
• POST /solve against a correctly configured, capturable target returns 202, and GET /events observes start → one or more delta → done{usage} in order.
• POST /solve while a previous solve is still streaming interrupts it immediately — the new solve's events begin, and the prior solve is marked interrupted rather than left dangling.
• A pre-flight guard failure (minimized target, black frame) produces no SSE event and no provider call — verified via a fake capture module in tests, and manually against a real minimized window.
• A provider error{kind} (from ticket 4's seam) reaches GET /events as a terminal error{kind} event.
• Two simultaneous GET /events connections observe an identical event sequence for the same solve.

Blocked by

#26 (Host process bootstrap & API key gate), #28 (Target window config surface), #30 (Live window capture session), and #27 (Provider seam) — the frame signals and the model call this ticket orchestrates.