fix(frank-zealot): key the ledger to the production boot; record the arm drop-in hijack

The cutover deploy's FIRST boot was not the shipped payload: a stale
frank-zealot.service.d/ptq1.conf from the bench window still pointed
FRANK_ZEALOT_ENV_FILE at /tmp/zealot-arm-current.env, so the unit booted the
unmeasured 27B PTQ1_0 arm (3 slots of 133,888, 21,188 MiB) while /health
answered 200, /v1/models echoed the alias and the e2e gate passed 33/33.
Drop-in retired to ~/.AGENTTRASH/20261018-zealot-ptq1-arm/; the 13:19 restart
is the shape the docs now quote (n_ctx_slot 262144, KV 13,056.00 MiB,
settled 17,922/6,203).

Corrections the production ledger forced:
- RS buffer is 150.75 MiB (3 cells) on the shipped spec-off shape; 452.25 MiB
  belongs to the SPEC-ARMED arms, where MTP depth 2 bills three seqs per slot.
  The drafter triples the recurrent state on top of its 3,072 MiB of f16 KV.
- Decode measured 168.4-168.7 t/s single-stream and ~300 t/s aggregate over
  three streams (102.8 each). Wall-clock timing of a generation that stops on
  its own reads 4x low (72 t/s for a 24-token countdown) - measure with
  ignore_eos and read the engine's timings.
- OpenWebUI stores both decoration values inside JSON columns (params/meta),
  and frank-dragoon's context.length had drifted to 262,144 against its own
  200,704 ceiling; both re-keyed in the live DB.

New law in AGENTS.md: after deploying a recently-benched LLM service, check
DropInPaths, then /proc/<pid>/cmdline, then the ledger. Health checks cannot
see the payload.

serverAppConfigs-docs/Dankclaw/OpenWebUI.md

@@ -53,11 +53,18 @@ Policy while candidate arms held the port): the candidate — Ternary-Bonsai-2-*
 PQ2_0 with the MTP head, 3 × 262,144 — was **deployed as production**, so the
 picker row below was re-keyed to it (see the next paragraph).
 
-The `model` table carries exactly one decoration row, `frank-zealot`
-(context length 262,144 = the per-slot window since 2026-10-18; description
-re-keyed the same day to Ternary-Bonsai-2-9B PQ2_0 + MTP + Q8_0 vision mmproj —
-the row's `description` is live DB state, so a payload swap must re-key it in
-the database too, not only in the repo).
+The `model` table carries exactly two decoration rows, `frank-zealot` and
+`frank-dragoon`. Both the context length and the description live **inside
+JSON columns** — `params` holds `{"context": {"length": …}}` and `meta` holds
+`{"description": …}`; there is no `context_length` or `description` column, so
+`sqlite3` one-liners against those names fail. Re-keyed 2026-10-18:
+`frank-zealot` → 262,144 with the Bonsai-2-9B description, and `frank-dragoon`
+→ 200,704 (its `params` had kept the pre-lowering 262,144 window from
+2026-10-17 while its own description already said 200,704). These rows are
+live DB state, so a payload swap must re-key the database too, not only the
+repo. There is no `sqlite3` binary on Dankclaw — use `python3 -c` with the
+stdlib `sqlite3` module, and take a `Connection.backup()` snapshot first (the
+DB is in WAL and the app is live).
 
 A third gate sits *after* the table, and it is the one that bites family
 accounts (2026-10-07): a model row is only visible to a non-admin user when