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-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