M4: add durable named Save Points

A Save Point is a name for a story position, and restoring one is head
movement. That is the whole architecture, and it is what ADR 012 and
BUILD-MILESTONES' note on M4 asked for: M3 made the head a stored
(branch, depth) and made arriving at one a row lookup plus a state restore,
so a Save Point needs no restore machinery of its own.

What the user gets:

- Name the moment they are reading, keep playing, restart the app, and come
  back to it. Restoring moves the story back and deletes nothing: the later
  turns stay, Redo still walks forward into them, and writing something
  different is what starts a new line while the old one is kept.
- Rename, delete, and a list, in a Save Points panel beside the branch panel,
  with a Save Point button next to Undo and Redo. Both confirmations say what
  is *not* destroyed, because that is the part the screen cannot show.
- Save Points survive export and import.

What was deliberately not built:

- No second restore path. `head.move_to_node` is the only new movement: its
  depth half is M3's `head.move_to` unchanged, and its branch half is the
  single assignment `switch_branch` already makes. No head field is written
  in the checkpoint router, nothing reconstructs state, nothing prunes a
  memory, nothing copies or deletes a turn, and restore never forks — the
  first write below the restored head does, through `fork_if_behind_head`.
- No automatic cleanup. A Save Point behind the head, or naming a line the
  story left, is doing its job (STORY-BRANCH-SEMANTICS §19). The one removal
  is a cascade: deleting a branch takes its Save Points, as it takes its
  memories, because the story they named went with it.
- No new ADR. ADR 012 already decides the architecture, and a table is not a
  decision.

The one call the planning package did not already make: restore moves the
branch half of the head only when the coordinate is off the path being read.
Doing it unconditionally would quietly hand back an abandoned continuation
whenever a Save Point in a shared prefix was restored; never doing it would
make a Save Point on a departed line unrestorable, which contradicts §19.
TECHNICAL-DESIGN §8.8 records it.

Schema: a `checkpoints` table holding a name, an optional note and a
(branch, depth) coordinate — no copy of any story. `create_all` builds it as
it did `memories` and `branches`; migration 80 adds the index. No backfill,
because nobody had named a position before M4.

The coordinate is deliberately not an action id: one coordinate holds every
attempt at a turn and exactly one is live, so a coordinate follows a retry
where a row id would pin a take the story no longer tells.

Tests: 680 pass (638 before). 42 new in tests/test_save_points.py covering
D11-D14, I04, L03, E-series lineage and memory isolation after restore and
divergence, the edge cases, and an M3-database migration. One pre-existing
fixture in test_tree_migration.py needed `checkpoints` added to its drop
list — SQLite refuses to drop a table another table references.

Not verified: the browser. No session has had a usable one, so the Save
Point panel's DOM behaviour is unobserved — as M3's Redo control still is.
The twenty-step sequence was driven over HTTP against a live server with a
real process restart instead, and all seventeen checks pass. M4 is
implemented, not accepted: no review has been written.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PWU4gTfLYY6Qq9U7aa9Qw2

planning/README.md

@@ -4,8 +4,9 @@
 
 **Current state:** Phase 0 complete; AI-DnD forked as the production base;
 milestones **M1, M2 and M3 implemented and accepted** (M3: 2026-09-03).
-**Next:** **M4 — named Save Points.** Its brief has not been written yet, and
-writing it is the current action.
+**M4 — named Save Points — is implemented (2026-09-03) and awaiting review.**
+Its implementation report has not been written, and writing it is the current
+action. Do not begin M5.
 
 **Package version:** see `VERSION.md`, which records what each revision changed
 and why.
@@ -132,7 +133,9 @@ that is the one the next milestone's planning has to consult:
 
 Completed earlier milestones are in `archive/milestone-reports/`. When M4's
 report lands, M3's moves there too: a milestone report is useful during the
-immediate next milestone and historical afterwards.
+immediate next milestone and historical afterwards. **M3's report has not moved
+yet**, because M4's does not exist — the rotation belongs to M4's closeout, not
+to its implementation.
 
 ## The decision this package rests on
 
@@ -234,8 +237,8 @@ Milestone M3                        COMPLETE (2026-09-03)
   active-head export                and ADR 012
         |
         v
-Milestone M4                        NEXT — brief not yet prepared
-  named Save Points
+Milestone M4                        IMPLEMENTED 2026-09-03 —
+  named Save Points                 awaiting review; no report yet
         |
         v
 M5-M11, one at a time               see BUILD-MILESTONES.md
@@ -245,15 +248,15 @@ M5-M11, one at a time               see BUILD-MILESTONES.md
 
 **One milestone at a time. Do not begin a milestone before its brief exists.**
 
-**No M4 brief has been prepared.** Writing one is the current action, informed
-by the post-M3 corrections below, by the note `BUILD-MILESTONES.md` attaches to
-M4, and by **ADR 012**, which records the head-movement mechanism M4 must reuse
-rather than reimplement.
+**M4 is implemented and unreviewed.** Its implementation report is the current
+action; M5 does not begin before that report is written and accepted.
 
-One M3 condition remains open and does not block M4: the required **browser
-smoke test has not been performed**, because no session in which M3 was
-implemented or reviewed had a browser available. See
-`reports/M3-IMPLEMENTATION-REPORT.md` §M and §W.4.
+Two conditions remain open. The **browser smoke test has still not been
+performed** — now for M3 and for M4 — because no session so far has had a usable
+browser. See `reports/M3-IMPLEMENTATION-REPORT.md` §M and §W.4, and the M4 status
+block in `BUILD-MILESTONES.md`. And **no M4 review exists**: the status block was
+written by the implementation and records what it built, which is not the same as
+a reviewer having read it.
 
 ## What each milestone closeout corrected