docs(llm): record the gufo cutover verification

Live numbers from the 2026-09-28 deploy: 13 s load to listening, RSS
30.6 GiB, ttft 549.8 ms / inter-token 24.2 ms on a short prompt, and a
green contract battery (health, ready, /v1/models at 262,144, content +
reasoning_content, tool_calls, SSE, and a two-turn tool loop).

Also recorded: gufo accepts every request field the harness sends in
extraBody and the full reasoning_effort set, both verified 200 — which
is why models.yml's reasoningEffortMap fold is now optional rather than
required, and why it is being kept anyway.

serverAppConfigs-docs/LLM/frank-large-gufo-qwen38-27b.md

@@ -108,6 +108,24 @@ architecture, driver and queue budget.
 - **Memory:** gufo's own table puts the 8-bit target at **50.58 GiB** peak
   with context capacity 262,144, against the iGPU's ~114 GiB GTT aperture.
 
+### Measured at the 2026-09-28 cutover
+
+Live on Dankclaw after `deploy.sh dankclaw --service frank-large`:
+
+- **13 s** from `load_started` to `listening` (target 8 s, drafter 2 s,
+  session 3 s), against a 20-minute `LLM_WAIT` budget — a redeploy no longer
+  sits in a load wait.
+- **RSS 30.6 GiB**, VSZ 87.3 GiB; host `used` 81 GiB of 121 GiB, i.e. the
+  same order as the llama.cpp deployment it replaced.
+- A short-prompt live request returned
+  `Server-Timing: ttft;dur=549.8, inter_token;dur=24.2, max_inter_token;dur=166.9`
+  (≈41 tok/s). Short-prompt decode is gufo's *winning* regime; see the depth
+  table above before quoting it as the endpoint's number.
+- Contract battery, all green: `/health` 200, `/ready` 200,
+  `/v1/models` → `frank-large` with `context_length 262144`, a chat
+  completion carrying both `content` and `reasoning_content`, a `tool_calls`
+  response with `finish_reason: tool_calls`, and SSE streaming.
+
 ## Client contract — what actually changed
 
 Everything the fleet depended on still holds: port 7770, alias `frank-large`,