docs: 1.0 documentation restructure

Split root CLAUDE.md into 19 per-directory files scoped to their source area.
Roll v0 history into docs/ARCHIVE.md; retire CONTEXT.md, CONTEXT-ARCHIVE.md,
PLAN.md, COMPLETED.md. Move plan docs under docs/. Rescue 9 live deferrals
into docs/TODO.md.

docs/product/versioning-and-release.md

@@ -8,8 +8,8 @@ concrete and decidable:
 2. **A beta side-channel** — so development can continue and a beta build run
    *alongside* the stable one without the beta clobbering the release.
 
-This doc holds the *why*, the forks, and a recommendation. When Daniel picks, the
-tickable points land in `PLAN.md` and the deploy/build wiring hands off to dev-ops.
+This doc holds the *why*, the forks, and a recommendation. The tickable points'
+landed history is in `docs/ARCHIVE.md`; the deploy/build wiring hands off to dev-ops.
 This is a framing note; it changes no source or CMake.
 
 Status: framed by product-designer (2026-07-26); **all four forks settled by Daniel
@@ -54,7 +54,7 @@ Two sharp edges follow directly and recur throughout this note:
   Both binaries reading/writing the same namespace on the same open project means a
   **beta can read — and rewrite — a stable project's saved bank/view state.** Given
   the forward-only migrations already in the design (legacy `bank_index` retired
-  after promotion; `banks` authoritative thereafter — CONTEXT.md §Multi-bank), a
+  after promotion; `banks` authoritative thereafter — `docs/ARCHIVE.md` §Phase B), a
   beta that writes a newer schema into a project a user then reopens in stable is a
   real corruption path, not a theoretical one.