Draft workspace: keep the losing writer's text visible after a stale-save reload

[TusanHomichi]

Problem or outcome

When two contributors edit the same daily draft, the revision contract refuses the losing save as stale_save and the workspace visibly reloads the winning content — correct per ADR 0008 (one working copy, never a silent overwrite). But the losing writer's divergent text is simply gone from the screen at that point. Anything they had typed since the winning save exists nowhere they can reach, which turns an honest concurrency refusal into lost work.

Outcome: after a stale-save reload, the refused buffer stays available read-only — for example a collapsed "Your unsaved text from before the reload" section per edited field, copyable, discarded on navigation. The writer merges by hand; the system never merges.

Scope

• Web interface only (web/src/routes/drafts/[id]/+page.svelte); no service, API, or schema change
• The revision contract, refusal codes, and reload behavior stay exactly as shipped in drafts(attribution): daily evaluation drafts with contributor history #29/review(workflow): single-step review for daily drafts #31
• Explicitly not: automatic merging, draft-content diffing, or storing the refused buffer server-side — the refused text never becomes record content unless the writer types it back in

Acceptance criteria

• After a stale-save reload, the writer can see and copy the text of their refused buffer where it differed from the reloaded content
• The preserved buffer never persists anywhere (component state only) and clears on navigation
• e2e: two-writer race where the loser recovers their sentence by copy after the reload
• All repository gates green

Low priority — a usability nicety on a correct contract, noted during the Milestone 3 slice-3 review.

Related roadmap, decisions, or issues

• Refs Milestone 3 design: sessions, drafts, and attribution (owner decisions needed) #22, ADR 0008 (one working copy; stale saves refused typed); shipped behavior from #29