Planning v3.9: record M11's long-run evidence, and correct what v3.7 claimed

The planning package still described M01 as outstanding. It now records the
evidence run on 96c1bf5 and the two product defects found on the way. It also
corrects three statements that were never true.

- V1-ACCEPTANCE-TESTS.md: result blocks for M01-M04. M04 is recorded as
  recovered through authoritative state, with the owner's acceptance of that on
  2026-09-13 and the positional precondition explained.
  Correction: v3.7 said this file carried M11 results against every REQUIRED
  test. None were written, and the per-test matrix is the M11 report's §F. The
  §P3 M11 disposition said the report records the identity diagnostic's
  findings. It does not, and the disposition now says so.
- BUILD-MILESTONES.md: the M11 status block records the long-run evidence,
  the write-lock and protocol-leak defects, and what is left for the reviewer.
- DATA-MODEL.md §28B: M11 added two columns, not one.
  settings.context_window_override (migration 94, ef25b0a) was never
  recorded.
- TECHNICAL-DESIGN.md: "Background failure observability" gains the rule
  that nothing in a turn writes before the model call, and new §15.4 records
  that stored narration carries story only, with the extractor's rules.
- CONTEXT-AND-MEMORY.md §51 and ADR 013: as-implemented notes for the same
  two fixes.
- README.md and VERSION.md: status, milestone map, stop rule, and the v3.9
  entry.
- M11 report §Q: the "not revised" note is replaced by what v3.9 revised.

No requirement changes. No code changes.

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

planning/CONTEXT-AND-MEMORY.md

@@ -1127,6 +1127,17 @@ If embedding generation fails:
 
 Derived-memory failures must not block story persistence.
 
+**As implemented (M11).** Two more rules, both learned from a long run in which
+every turn was accepted while the memory bank quietly stopped filling:
+
+- **A failure must be recordable.** The record is itself a write. It is made after
+  the failed session has been rolled back, so the status the reader sees
+  (`derived_status`) never reads `idle` over a failure.
+- **The turn must not cause it.** A turn that held SQLite's write lock through the
+  model call locked every post-turn write out for the length of the reply. Nothing
+  in a turn writes before the model call (`TECHNICAL-DESIGN.md`, "Background
+  failure observability").
+
 ## 52. Offline Operation
 
 All context and memory operations must work locally.