docs: CB-591 gateway page had two claims that went stale

The gateway's chat model is served under the stable alias `acoder`, and the
model behind that alias changed on 2026-08-28 — it is Qwen3.8-27B now, not
DeepSeek-V4-Flash. The old name is still served, so nothing broke, but it
names a model this is not.

Two claims on the page were wrong as a result, and both were written as
current facts rather than dated measurements:

- `/v1/models` returns exactly `["deepseek-v4-flash"]` — it returns 6 ids
  now. This sat under a heading saying it needs no re-testing.
- the status banner said `local` and `gx` are both at `weight: 100` —
  `local` is at 0.

Measured today against the live gateway: /v1/models returns acoder,
qwen3.8-27b-nvfp4, deepseek-v4-flash and three embedding names; a completion
sent as `deepseek-v4-flash` comes back reporting `"model": "acoder"`, which
is the alias in plain sight. /v1/deployment reports generation
2026-08-28-qwen3.8-27b-nvfp4.

§2 and §3 are left alone. They are the August plan, and rewriting them would
destroy the record of the migration.

fleetd.yaml moved to `acoder` in the same change. It is not tracked here.

docs/CB-591-Gateway-Migration.md

@@ -5,6 +5,21 @@
 here took a revert and two upstream fixes — see §7.1, which is the useful part of this document. One
 risk is **accepted rather than solved**: a stream cut by any mid-response timer arrives as HTTP 200
 with no terminator, and our third-party members cannot detect it (§7.2).
+
+> **Superseded in part — 2026-09-13.** Two claims on this page are no longer true of the live fleet.
+> I measured both on this host today.
+>
+> 1. **The model is named `acoder` now, not `deepseek-v4-flash`.** `acoder` is a stable alias, and
+>    the model behind it changed on 2026-08-28: it is Qwen3.8-27B, not DeepSeek. The old name is
+>    still served, so nothing broke — the gateway answers it and reports `"model": "acoder"` in the
+>    reply, which is how you can see for yourself that it is an alias. `fleetd.yaml` moved to
+>    `acoder` on 2026-09-13. Do not guess behaviour from the name; ask the gateway's own manifest,
+>    `GET https://llm.ltms.dev/v1/deployment`, and read its `generation` field.
+> 2. **`local` sits at `weight: 0`, not 100.** Only `gx` is auto-selected today.
+>
+> §2 and §3 below are the plan as written in August. They are the record of the migration, so they
+> stay as they are. If this note stops matching `fleetd.yaml`, re-measure and rewrite the note.
+
 · **Upstream:** [systems/vms wiki → LLM and MCP Gateway](https://git.ltms.dev/systems/vms/wiki/LLM-and-MCP-Gateway)
 · **Upstream issue:** [systems/vms#31](https://git.ltms.dev/systems/vms/issues/31)
 
@@ -380,7 +395,10 @@ one turn; this one costs the whole task and is indistinguishable from a slow wor
 
 - Token accepted on both surfaces. **Unauthenticated → 401**, so the Caddy proxy really does gate —
   the wiki's "SecurityPolicy fails open" warning is about the gateway itself, not the edge.
-- `/v1/models` returns exactly `["deepseek-v4-flash"]`, so trap 3 is clear.
+- `/v1/models` returned exactly `["deepseek-v4-flash"]` **on 2026-08-15**, so trap 3 was clear
+  then. It returns 6 ids now — `acoder`, `qwen3.8-27b-nvfp4`, `deepseek-v4-flash` and three
+  embedding names — measured on this host 2026-09-13. The exact-name rule still holds; the
+  one-item list does not.
 - **Reasoning survives both surfaces** — see §3b above.
 - The launcher's generated opencode provider block is correct, carrying a real 48-character `llmk-`
   key rather than the `fleetd-local-noauth` placeholder.