wiki-migrationlisted

# wiki-migration The minimal registry + runner `/ren:update` (and `/ren:doctor`'s schema-version check) drive migrations through. Per spec §7.1, donor's heavy chain-computer + registry-template + JSON-schema-validated verify-page.sh machinery is **pre-excluded** for 0.2 — this is deliberately thin. ## `schemas.json` Enumerates only the page types actually stamped by something in this repo: `identity`, `l2-map` (both still at their initial schema, no migrations yet), and `routine-spec` (schema 3, migrated via `routine-spec-1-to-2` then `routine-spec-2-to-3`). Not a speculative full taxonomy — add an entry only when a page type gets a real migration. ## The env-mapping shim (load-bearing) `migrations/routine-spec-1-to-2/` was **carried verbatim** from donor and expects `SF_WIKI_ROOT`/`SF_SNAPSHOT_DIR`. `migrations/routine-spec-2-to-3/` was written fresh for this repo and expects `REN_WIKI_ROOT`/`REN_SNAPSHOT_DIR`. `run_migration()` sets **both** pairs of env vars to the same values on every invocation, so the same thin runner drives either migration directory without needing to know in advance which naming convention its `migrate.sh` reads. This is documented here rather than fixed at the source, because "carry verbatim" for 1-to-2 was an explicit instruction (Task 6.3) — the shim is the seam, not a bug to clean up. ## Behavior 1. `load_registry()` reads `schemas.json`. 2. `migration_chain(page_type, from_version)` returns the ordered subset of that page type's migration