docs: record the wire rename, the OpenWebUI re-key, and the frank-primary bench drop-in trap

- AGENTS.md Model Config: the Protoss names are now the ids on the wire
  (per-endpoint knob named); verify a rename on /v1/models, never on a chat
  response — radiance echoes the requested name
- OMP Harness.md: harness id == served id; one id per model everywhere
- Homepage.md: the docs-page "api id" annotations and the switchover promise
  are retired
- OpenWebUI.md: the id-keyed trio (model row, access_grant, api_configs
  model_ids) is a foreign-key set — re-key it in the same deploy; plus the
  contenteditable-composer probe note
- frank-secondary/frank-large/frank-primary runbooks: served ids
  frank-zealot/frank-dragoon/frank-archon, and the bench.conf drop-in that
  made every frank-primary deploy since 2026-10-08 04:09 restart the staging
  worktree behind a green health gate

serverAppConfigs-docs/LLM/frank-large-flash-server-v2-swift15.md

@@ -88,7 +88,7 @@ resume law throughout; no token — the repos are public).
 | `HALOGEN_MAX_TOK` / `HALOGEN_MAX_TOKENS_CAP` / `HALOGEN_QUEUE_TIMEOUT` | 8192 / 65536 / 7200 | 8192 is only the per-request DEFAULT (the harness sends at most its `maxTokens` 45,056); the cap/timeout pair is COUPLED per FLAGS.md (65536 at ~10 t/s serial needs > 6550 s) |
 | `HALOGEN_TEMPERATURE` / `TOP_P` / `TOP_K` | 1.0 / 0.95 / 20 | the card's thinking recipe as SERVER-SIDE defaults — the engine HAS a sampler now, so an absent temperature is no longer greedy; models.yml extraBody matches it (consistent, not load-bearing) |
 | `HALOGEN_WEIGHTS_LOCK` | 1 | card's belt-and-braces; the engine pins weights by default on v2 (`HALOGEN_FLASH_PIN_TRUNK=0` is a w4b-only knob and is REFUSED by v2) |
-| `HALOGEN_MODEL_ID` / publish | frank-large / 7770:8731 | unchanged aliases; engine port 8730 never published |
+| `HALOGEN_MODEL_ID` / publish | **frank-dragoon** / 7770:8731 | served id renamed 2026-10-09 (service/unit/env keep `frank-large`); engine port 8730 never published |
 | MTP depth | default 2 | FLAGS.md: 2 is best all-round, 3 for code — Frank's traffic is agent/prose |
 
 **Memory ledger** (121.2 GiB unified, the referee is the boot ledger):

serverAppConfigs-docs/LLM/frank-primary-radiance-swift15-w4dn8.md

@@ -157,6 +157,34 @@ MiB measured**); the serve size floor `FRANK_PRIMARY_RAD_MIN_MIB` moves
   pools 57.84 GiB, cards settled 1.41 GiB free, `serving on :7770`.
   Live decode probe (512 tokens, streamed, temp 0): ~190 t/s.
 
+### Wire rename + the bench drop-in trap (2026-10-09)
+
+`FRANK_PRIMARY_SERVED_NAME` moved `frank-primary` → **frank-archon**; the
+service, unit, scripts and env file keep the old name. Radiance is the only
+fleet engine whose `/v1/models` listing reflects the flag, and it echoes the
+**requested** model name in chat responses — so a chat probe that returns 200
+proves nothing about the served id. Always read `/v1/models`.
+
+The first deploy after the edit came up green and `/v1/models` still said
+`frank-primary`. Cause: a campaign leftover drop-in
+`/etc/systemd/system/frank-primary.service.d/bench.conf` (2026-10-08 04:09)
+overrode BOTH `Environment=FRANK_PRIMARY_ENV_FILE` and `ExecStart` to the
+staging worktree `/home/dank/serverAppConfigs-swift15`. Every
+`deploy.sh dankserver --service frank-primary` since then restarted the
+staging tree: green health gate, old configuration, silently. Verified before
+removing: the staging `serve-frank-primary.sh` and `frank-primary.service`
+are byte-identical to the checkout, its `frank-primary.env` differed only by
+the alias line, and its HEAD (`8375567`) is an ancestor of `main`. The
+drop-in is staged in `/home/dank/.AGENTTRASH/20261009-frank-primary-bench-dropin/`.
+After `daemon-reload` + restart, `/v1/models` reports `frank-archon` (boot
+healthy in 102 s, shape unchanged: fp8 KV, spec depth 2, seqs 3, vram pair
+26071/3543).
+
+**Deployer blind spot:** `deploy.sh` plans from repo paths and gates on the
+port. It cannot see host-side drop-ins, so unit drift is invisible to a green
+run. After an LLM deploy, verify the served configuration behaviourally
+(here: `podman inspect <name> --format {{json .Config.Cmd}}` and `/v1/models`).
+
 
 
 ## Deploy + verify

serverAppConfigs-docs/LLM/frank-secondary-llama-qwen35-9b-q6k-2x200704.md

@@ -25,7 +25,7 @@ conversation slot and unquantized KV back.
 | | |
 |---|---|
 | Host / device | Dankclaw (192.168.0.143), RTX 3090, 24,576 MiB |
-| Endpoint | `http://192.168.0.143:7771` — alias `frank-secondary`, `/v1` OpenAI surface |
+| Endpoint | `http://192.168.0.143:7771` — served model id **`frank-zealot`** (`ALIAS` in the env; the SERVICE keeps the `frank-secondary` name), `/v1` OpenAI surface |
 | Runtime | llama.cpp master (0.5.0-dev, commit `5fc4f3c`), CUDA sm_86 build `…/llama-master/build-cuda/bin/llama-server` (`GGML_CUDA_FA_ALL_QUANTS=ON`); `qwen35` is registered in the build's own `src/llama-arch.cpp` and `src/models/qwen35.cpp` exists at that commit |
 | Unit | root systemd `frank-secondary.service` ([`scripts/frank-secondary.service`](../../scripts/frank-secondary.service)), `User=dank`, `Restart=on-failure`, `LimitMEMLOCK=infinity` |
 | Serve script | [`scripts/serve-frank-secondary.sh`](../../scripts/serve-frank-secondary.sh), tunables [`scripts/frank-secondary.env`](../../scripts/frank-secondary.env) |
@@ -96,7 +96,15 @@ which is what the engine printed. The `n_ctx_seq (200704) < n_ctx_train
 (262144)` line is informational (a context **below** the trained window is
 safe; the Gemma4 era's warning was the opposite case, a drafter running 53 %
 **past** its window). Weights load in ~6 s from page cache; `/health` answers
-`{"status":"ok"}` and `/v1/models` serves the alias `frank-secondary`.
+`{"status":"ok"}` and `/v1/models` serves the alias `frank-zealot`.
+
+**Wire rename (2026-10-09):** `ALIAS` moved `frank-secondary` → `frank-zealot`,
+so the served id matches the harness model id and the family-facing name.
+Consumers re-keyed in the same change: OpenWebUI (`model` row, `access_grant`
+row, `openai.api_configs` index-2 `model_ids`) and `models.yml` (already
+renamed 2026-10-08). llama.cpp does NOT validate the requested model name —
+it answers and echoes the served alias — so a stale client keeps working;
+the picker and any id-keyed grant is what breaks. See [[OpenWebUI]].
 
 The deploy's Playwright gate passed (33 tests) and the fleet e2e set is
 unchanged.