Local-first persistence deploy

# Local-first persistence deploy

Deploy local-first persistence for the document editor. Engineering work is on branch `feat/local-first-backward-compat` in `yawp-2.0` and is ready to ship pending a backward-compat dual-write design.

## Problem

The document editor today writes through to the server on every change, with limited offline tolerance. A student on a flaky connection can lose work. Local-first persistence stores edits locally and syncs to the server, with the local copy as the source of truth between sessions.

## Status

Engineering is largely complete on `feat/local-first-backward-compat`. The blocker is the dual-write design — flipping the default requires existing documents to migrate cleanly without losing or double-writing data.

May 8 Immigration Essay email: the current submitted document was present in production and had normal save history after the rewrite, but the student's original draft had no server-side save evidence. That keeps this item on the radar as a data-integrity and observability question: if a student believes work existed, we need better confidence about whether it was saved locally, synced, overwritten, or never persisted.

## Goals (rough)

- Local-first persistence is the default for document editing.
- Existing documents continue to work during and after the migration (backward-compat hard requirement).
- Offline edits sync cleanly when connectivity returns.

## Open questions

- [ ] Dual-write strategy: write through both paths during rollout, then flip after soak; or stage-flip per-cohort?
- [ ] Conflict resolution if local and server diverge during a long offline window.
- [ ] Data integrity verification before flipping the default.

## Engineering handoff

Not ready as a PM-driven spec — engineering will drive the dual-write design. PM tracks this for visibility on rollout impact and pilot communication.