docs: wiki staleness sweep (Fable-orchestrated Opus audit)

Audited all 40 docs/ against the live codebase; fixed factual staleness in 23,
14 were clean. Highlights (all verified against code):
- equipment -> machines (ADR-011 rename) in INSTALL/DEPLOY-WINDOWS-IIS,
  PLUGIN-GUIDE, GE-ENFORCE, ROADMAP.
- Versions refreshed: contract 0.10.0 -> 0.13.0, product 0.5.0 -> 0.7.0, plus
  plugin example core_version pins.
- Bundled set corrected to the current 13 (PLUGINS.md 7 -> 13 rows; DEPLOY
  eleven -> thirteen).
- Per-plugin Alembic chain workflow (ADR-008) replacing stale core-chain steps
  in PLUGIN-QUICKSTART / BACKUP-RESTORE; deploy adds plugin upgrade-all.
- Frontend plugin staging (ADR-010) replacing 'no frontend plugin system yet'
  in PLUGIN-GUIDE; view/route paths repointed to plugins/<name>/frontend/.
- Corrected file paths (MapView.vue, manifest_schema.json), CLI (shelf-list),
  API gating (GET /api/plugins is optional-jwt), WJF 15 -> 16 stages, and
  retired Collector/PC-Types settings pages (ADR-012).
- ge-enforce proposal marked ACCEPTED/built.

docs/adr/ADR-004-deployment-topology.md

@@ -63,16 +63,21 @@ The framework provides:
 
 ## Migration strategy (resolved)
 
-Deploys run a single core Alembic chain: `flask db upgrade`. Bundled plugins do
-NOT carry their own migration chains - their tables are folded into the core
-chain (migration `7c04_fold_plugin_schema`). This was a deliberate resolution of
-the Phase 7B footgun where bundled-plugin baselines and the core baseline both
-created the same tables, so `flask plugin upgrade-all` would conflict. A fresh
-`flask db upgrade` reproduces the live schema exactly (verified on a scratch DB).
+Deploys run two commands: `flask db upgrade` then `flask plugin upgrade-all`
+(lean/ADR-014 sites add an optional `flask plugin prune-schema` at initial
+provisioning). The core Alembic chain applied by `flask db upgrade` creates the
+full core AND bundled-plugin schema through the chain head (this includes
+migration `7c04_fold_plugin_schema`). But every bundled plugin still carries its
+own Alembic chain per ADR-008: `flask plugin upgrade-all` stamps each plugin's
+own chain (the `alembic_version_<plugin>` tables) and applies any plugin-specific
+migrations added after the ownership cutover. The earlier Phase 7B state that
+folded everything into core with no per-plugin chains was superseded by ADR-008's
+per-plugin ownership. A fresh `flask db upgrade` reproduces the live core schema
+exactly (verified on a scratch DB).
 
-External (out-of-tree) plugins per ADR-003 may still ship their own migrations;
-the framework supports per-plugin chains for them. Only the in-tree bundled
-plugins are consolidated into core.
+External (out-of-tree) plugins per ADR-003 ship their own migrations too; the
+framework runs the same per-plugin chain mechanism (ADR-008) for both bundled and
+external plugins.
 
 ## Open questions