NU-013 nuron-web: reviewer surface, diff editor, merge screen, query box #27

Part of #30.

nuron-web (SvelteKit + Bits UI): the reviewer's surface and the query box.

Build

• Upload.
• Review queue — list, open, read.
• Body editor + diff view. On re-ingest, show raw-v1 → raw-v2 alongside the reviewer's prior
  edits so they can re-apply.
• Merge confirmation screen — auto-joins shown as information; ≤5 merge candidates as
  questions, every one defaulting to "not the same".
• Query box consuming the SSE stream.
• Citations resolve to the Reviewed Source by default. "View original" is a deliberate second
  action — showing the raw original by default would hand users the uncorrected content the
  reviewer just fixed, undoing the gate.

Two screens, one sitting

Merge candidates need the document's entities, which come from the Compiler, which runs
after content approval. So merge confirmation cannot share a screen with content review — the
entities do not exist yet.

Flow: content review → approve → compile (seconds) → merge screen → confirm → persist. One
interruption for the reviewer, but two real persisted states (awaiting_review,
awaiting_merge_confirm) because a reviewer may close the browser between them and restart-safety
requires resuming where it paused.

Why this is ready-for-human

Reviewer fatigue is the failure mode that quietly kills the product: a tired reviewer who
rubber-stamps produces a confidently wrong graph. The affordances that prevent it — safe defaults,
keyboard-driven approve/next, a diff that makes re-applying edits cheap — are judgement calls, not
a spec.