docs(vault): fleet-wide fact re-verification pass (67 pages)

The docs-fact census wave re-read the live hosts and re-keyed every page
it could: runtime/payload identities, ports, sizes, ledger figures, unit
state, and the retirement banners that drifted as the fleet moved. The
wave was interrupted mid-run, so this commit carries only what passed the
integrity gates: every touched page parses (front matter or H1+status
convention intact, balanced fences, no truncated tables, trailing
newline), the docs_completeness and link-integrity seams are green, and
bats is 384/384.

Numbers that this session proved on live hosts are keyed to the measured
value, not the page's earlier claim.

serverAppConfigs-docs/LLM/frank-dragoon-flash-server-v2-native.md

@@ -94,6 +94,9 @@ the pool: **two long conversations can no longer share the endpoint** (two of
 ≤100k can). That is acceptable here because frank-dragoon carries the `slow`
 (medium-thinking) role and the `security-reviewer` subagent, not the
 interactive workhorse (that is frank-archon).
+Frank lifted exactly that concurrency limit on 2026-10-18 — see *Pool
+doubled for slot parity* below; that lift is COMMITTED but not yet deployed,
+so the sentences above remain the live truth until the next redeploy.
 
 **Memory ledger** (121.2 GiB unified), from the boot ledgers. The 22:20 boot
 printed `pinned 62.11 GiB in 1 range(s) in 1.6 s (41.0 GB/s)` trunk,
@@ -112,6 +115,43 @@ that long prompts read.
 `HALOGEN_FLASH_PIN_TRUNK=0` is **rejected by the v2 loader** — the trunk
 stays pinned. Disk-backing the weights is not a lever on this format.
 
+## Pool doubled for slot parity — committed 2026-10-18, awaiting redeploy
+
+`HALOGEN_KV_POOL_POSITIONS` **200,704 → 401,408** (commit `2b12716`), Frank's
+call: frank-dragoon's total in-flight context was **half** frank-zealot's —
+the llama.cpp endpoint runs one 401,408-position pool split into two 200,704
+conversations, while dragoon ran one 200,704-position pool behind its two
+slots, so one maximum-length request filled it and any second long
+conversation had to stay under ~100k (commit message;
+`scripts/frank-dragoon.env:26-27`, `:183-186`).
+
+- **The per-request ceiling does NOT move.** `HALOGEN_CTX` stays 200,704, the
+  native wall stays 262,144 (`HALOGEN_ROPE_YARN` law), and `models.yml`
+  `contextWindow` stays **155,648** — the pool is the shared budget behind the
+  slots, not the window. The serve seam enforces `HALOGEN_CTX ≤
+  HALOGEN_KV_POOL_POSITIONS ≤ HALOGEN_KV_SLOTS × HALOGEN_CTX`
+  (`scripts/serve-frank-dragoon.sh:85-95`); 401,408 is `slots × ctx`, the top
+  of the legal band, and exactly frank-zealot's pool number — parity, not
+  approximation.
+- Expected reservation **~10.8 GiB** at ~28 KiB/position (preflight formula,
+  `scripts/frank-dragoon.env:70-72`); the measured points beside it are 5.5
+  GiB at 200,704 (boot ledger 2026-10-18), 7.2 GiB reserved / 7.4 GiB billed
+  at 262,144, and 14.6 GiB at the 2026-10-06 shape's 524,288
+  (`scripts/frank-dragoon.env:49-52`, `:74-76`).
+- That RAM comes out of the n-gram table's page cache — FLAGS.md law: RAM the
+  pool takes is RAM that table loses.
+
+**Deploy state as of 2026-10-18: NOT yet deployed.** The live container
+(booted 2026-10-18 01:25) still runs `HALOGEN_KV_POOL_POSITIONS=200704` —
+verified in its `flash_serve` `/proc/<pid>/environ` and in the host-deployed
+`frank-dragoon.env` — and the 2026-10-18 boot ledger reserves `the KV pool,
+200704 positions (about 5.5 GiB)` with `74.1 GiB in all`
+(`/home/dank/logs/frank_dragoon.log`). Until the next
+`./scripts/deploy.sh dankclaw --service frank-dragoon`, the boot ledger keeps
+printing `2 slots over ONE 200704-position KV pool`; the first boot at the
+new pool must show `ONE 401408-position KV pool` and the ~10.8 GiB
+reservation — read that line before quoting 401,408 as live anywhere.
+
 ## Measured A/B — same battery, both boots (2026-10-17)
 
 Behavior probes ran against the live service (tagged `swift15` / `v2abl`);
@@ -267,6 +307,9 @@ restart; `webui.db.bak-20261017b` holds the pre-cutover row).
 **What the cut cost:** with pool == ctx one maximum-length request fills the
 pool, so two 200k conversations never coexist (two of ≤100 k do), and the
 harness window is now 155,648 — the 180 k compaction target of the 262,144 era
-is unreachable because the window itself is smaller. **What it bought:** 1.7
+is unreachable because the window itself is smaller. (The pool == ctx
+concurrency limit is superseded — on redeploy only — by *Pool doubled for slot
+parity* above; the window math stands, the pool never moves the ceiling.)
+**What it bought:** 1.7
 GiB back as page cache for the 47.68 GiB n-gram table (9.1 GiB against the
 2026-10-06 shape's 524,288 pool), and a smaller prompt-cache entry.