docs(sightsound): correct unknown-model-tag contract to live-probed behavior

Prior docs claimed unknown tags silently serve llama3.2:1b. Live probes on the
live endpoint disprove it: /v1/chat/completions answers HTTP 200 with a flat
{"error":"Failed to load <tag> model!"} body and no choices; /v1/completions
answers a nested OpenAI-shaped server_error (code 500) under HTTP 200. Valid
tags route per-request to the named model (response echoes the requested tag);
no restart needed to switch between registry tags. Corrected in the runbook,
the AGENTS.md runtime section, the serve-script header comment, and the
historical FastFlowLM incident note.

serverAppConfigs-docs/LLM/FastFlowLM NPU Inference.md

@@ -290,6 +290,11 @@ When a request names a tag that is not in the FLM registry, FLM does not return
 - FLM then loads the 1B model in place of the requested model.
 - The files now exist in `~/.config/flm/models/Llama-3.2-1B-NPU2` (1.3 GB) on dankclaw. A future unknown-tag request loads the 1B model silently, with no download and no error.
 
+**Correction (live-probed 2026-08-30):** the fallback no longer fires on the
+current serve path — an unknown tag now answers HTTP 200 with a flat
+`{"error":"Failed to load <tag> model!"}` body and nothing is loaded or served;
+`/v1/completions` answers a nested `server_error` (code 500) under HTTP 200.
+
 Keep client model IDs as FLM registry tags. Never send a service alias. Optional cleanup: move `~/.config/flm/models/Llama-3.2-1B-NPU2` (an incident artifact) to `.AGENTTRASH` so a stray tag re-downloads loudly instead of serving the wrong model.
 
 ### Request compatibility: the `developer` role (found 2026-08-16)