docs(vault): the four-slot ledger, and the resolver's funding law from the source

The shape block and boot ledger now quote the live 1.8.1 boot: experts 20.72 GiB
(78 %) / kv cache 5.64 GiB (21 %) = 747,492 tokens, 3.7 full-length sessions,
`--checkpoint-slots 40`, `queue_cap 32`, sampler 12 rows, `experts-from-host`
8.99 GiB a rank.

The KV Capacity law is rewritten from the pinned source instead of inference:
`core/mem/vram_budget.cpp:146-156` funds the cache as `elastic - expert_floor`,
`core/mem/kv.cpp:266` sets its ceiling from `max_seqs x max_ctx` (demand, never
funding), and `core/place/planner.cpp:100-104` makes the expert floor fall
one-for-one with `--host-pool-mib` — which is why +4,224 MiB of pinned host pool
bought the pool and cost 3.01 GiB of residency a card. The old "funds ~90 %,
never 100 %" phrasing was inference; the byte-identical 45,568 row is the ceiling
case, not a mystery. Slot-cost law carries the four-slot price (state +
checkpoint store + rows, still under the 25-row exact-wire bound). The two-slot
era is one row in Eras with its rollback commit. Date stamps in the trio
comments corrected to 2026-10-20.

scripts/frank-archon.env

@@ -48,7 +48,7 @@ FRANK_ARCHON_TP=2
 FRANK_ARCHON_TP_WIRE=wht6
 # Decode slots. A slot costs KV and pinned RAM, never decode: the cache target is
 # exactly MAX_SEQS x MAX_MODEL_LEN and the checkpoint store asks (1 + what the
-# retention policy keeps) per slot. Ordered 2026-10-21: FOUR slots over a pool of at
+# retention policy keeps) per slot. Ordered 2026-10-20: FOUR slots over a pool of at
 # least 700,000 fp8 tokens, rounding UP if the resolver cannot land it exactly. The
 # target is therefore 4 x 200,000 = 800,000 tokens and HOST_POOL_MIB decides whether
 # the cache gets it (expert_vram_floor, core/place/planner.cpp:100-104: the card must