fix(web): survive page reload without losing analysis or running LLM jobs

[jakob1379]

Problem

In the web UI (diffcore-web), a browser reload dropped everything: repo path, branch pair, analysis, and any LLM refinement / deep-analysis job that was still running. The server kept running the jobs and retained their SSE history, but the UI held all of that state only in React memory and never reconnected.

Fix (web only, desktop opts out)

• Session persistence in sessionStorage (per tab): repo path, base/head, the server's --repo it was recorded under, the repo the current analysis was run for, and whether the branch pair was picked explicitly.
• Restore on load: once settings are loaded, the analysis is re-run automatically, but only if the stored repo is the one that had actually been analysed. A stored session is ignored when the server's --repo changed, when the field holds an unsubmitted PR URL, or when the record is malformed.
• Branch pair: explicitly picked branches survive the reload; auto-detected ones are re-detected, so a reload still picks up a git checkout made in a terminal (the web UI has no HEAD watcher).
• Job persistence: streaming jobs are stored when started (scoped to repo + base + head) and forgotten only on a terminal SSE event. Forgetting on error was wrong: Chromium fires the EventSource error during page teardown, which wiped the list before the new page loaded.
• Reattach: the newest stored job is probed with a plain fetch (EventSource cannot expose HTTP status), pruned if the server no longer knows it or it belongs to another repo/branch pair, otherwise reattached with the running-state flags restored so cancel works via the stored id. Each stream closes only the EventSource it owns.
• Refinement results read the current analysis through a ref instead of a stale closure. This also fixes a pre-existing bug where a cached refinement was silently dropped on the first analysis of a page. A live result now wins over a cached one.

Preview

Verification

• Playwright suite: 226 passed, 2 skipped. New session-restore.spec.ts covers repo field + picked branches surviving reload, auto-detect resuming after changing the repo, and auto-detected branches being re-detected after reload.
• Manual against diffcore-web on this repo with real Claude CLI refinements (the demo-mode e2e suite has no server, so job reattach is manually verified only):
  • reload mid-job: running state and live stream restored, cancel via restored id stops the server job
  • job finishing during the reload window: applied on history replay
  • stale ids (server restarted), foreign-repo and foreign-branch jobs: pruned silently
  • changed --repo: field resets to the server's repo; unchanged: analysis restored without a click
  • half-typed, never-analysed path: restored into the field but not auto-analysed

[jamesaphoenix]

Should we store the refinment streaming in SQLite, then we could use:

• Hydrate from zustand -> API -> DB
• Catch up on any event's that have been missed with an event-order-id key with a stream-id key?

Thoughts on the above?

[jakob1379]

SQLite would make sense. I'll get to it soon enough

[jakob1379]

Went with sessionStorage rather than SQLite. The catch-up piece is already buil as ActivityManager::subscribe returns (history, receiver) and stream_job_events replays the full history before going live, so ordering is the Vec index and the stream-id is the job_id. That's what makes reattach-after-reload work.

SQLite's only real addition is surviving a backend restart, and if the server dies mid-refinement the LLM call dies with it

The actual defect in that area was unbounded growth of ActivityManager.jobs, fixed in 7c09fae with TTL eviction.

Happy to revisit SQLite if resumable server-side jobs become the goal, since that's the problem it'd genuinely solve.