test(flash-next-seat): depth-probe orca to 258K clean; record a blind instrument

Bisected context depth on the orcarouter checkpoint with non-repeating prompts
(unique random hex per probe, so prefix caching cannot short-circuit the
prefill). Six depths from 31,978 to 258,517 tokens, all served.

The load-bearing evidence is the engine allocator log: zero OOM, CUBLAS, or
illegal-memory entries across the run. That is the same detector that caught
the dealignai near-miss at 155K on the previous checkpoint, where it did fire.
The probe also ran under real concurrent operator load, making it a stricter
test than a solo run rather than a weaker one.

Positive control passed: a mis-sized first attempt produced a ~265K-token
prompt and got a clean 400 naming the limit instead of killing the engine, so
the probe could detect the failure mode it was looking for. Calibration for
re-runs: random hex words tokenize at 7.9 tokens/word here.

vLLM #54919 (long prefill starving decode for 3-7 minutes) did not reproduce:
258K prefilled in 28.9 s, roughly 8,900 tok/s, scaling near-linearly from 32K.

Records that the probe's memory-headroom half was BLIND and must not be reused.
It reported an identical 95,460 MiB used / 2,427 MiB free on every row across an
8x range of depths, which is the tell. Two causes: --kv-cache-memory pins the
pool and the engine logs "skipped memory profiling", so GPU usage is flat with
respect to depth; and the actual risk is a transient activation spike during
prefill, which before/after nvidia-smi bracketing structurally cannot observe.
Peak-activation headroom therefore remains unmeasured; the pass/fail result
rests on the allocator log alone.

Also qualifies the earlier 167.5 tok/s decode figure as a possibly-contended
lower bound, and records the operator's independent 140 tok/s average measured
in real use while this probe was loading the same card.

stacks/flash-next-seat/README.md

@@ -164,17 +164,38 @@ Open issues worth knowing about on SM120, none of them blocking:
 | **#54521** | Greedy decoding non-deterministic from `persistent_topk` in prefill | Affects any A/B on this seat — establish a noise floor before comparing |
 | **#54426** | fp8_e4m3 KV on the QSA path is an unmerged RFC | Why `--kv-cache-dtype` is **not** set to fp8 here |
 
-## Raising context
+## Context depth — PROBED 2026-09-14, clean to 258,517 tokens
 
-128K is a starting value, not a measured one. Before raising it, bisect with a
-**non-repeating** prompt — a repeated one hashes to cached blocks and never
-prefills deep, so it proves nothing. The `stacks/mog-sec` README records this the
-hard way: three successive context cuts all sized the *KV pool* while the crashes
-were governed by *processing depth*, which is a different number.
+262,144 is the configured ceiling and it has now been bisected with a **non-repeating**
+prompt (unique random hex per probe, so prefix caching cannot short-circuit the prefill —
+a repeated prompt hashes to cached blocks and never prefills deep).
 
-The point of a ceiling is the refusal. Below it the seat serves; above it vLLM
-returns a clean 400 naming the limit, instead of the engine dying and taking every
-in-flight request with it.
+| prompt tokens | 31,978 | 64,154 | 128,191 | 196,172 | 240,290 | **258,517** |
+|---|---|---|---|---|---|---|
+| result | ok | ok | ok | ok | ok | **ok** |
+
+**The load-bearing evidence is the engine's own allocator log: zero OOM / CUBLAS /
+illegal-memory / traceback entries across the whole run** — the same detector that caught the
+dealignai near-miss (`OOM on device 0 ... 466 MiB wanted, 403 MiB free`) at 155K on the
+previous checkpoint. It fired then; it is silent here. The run also happened **under real
+concurrent operator load**, which makes it a stricter test than a solo probe, not a weaker one.
+
+**Positive control passed.** A mis-sized first attempt built a ~265K-token prompt and got a
+clean `400` naming the limit rather than killing the engine — so the probe could detect the
+failure it was looking for. (Calibration for anyone re-running it: random hex words tokenize
+at **7.9 tokens/word** on this tokenizer.)
+
+**#54919 did not reproduce.** That issue reports long prefill starving decode for 3-7 minutes;
+258K prefilled in **28.9 s** (~8,900 tok/s), scaling near-linearly from 32K.
+
+⚠⚠ **DO NOT reuse the memory-headroom half of that probe — the gauge was blind.** It sampled
+`nvidia-smi` before and after each request and reported an identical 95,460 MiB / 2,427 MiB
+free on *every* row. Two reasons: `--kv-cache-memory` pins the pool and the engine log says it
+**"skipped memory profiling"**, so GPU usage is constant regardless of depth; and the risk is a
+*transient* activation spike **during** prefill, which before/after bracketing structurally
+cannot see. Identical readings across a 8x range of depths are the tell. Real peak-activation
+headroom needs in-process sampling during the prefill. The pass/fail result stands on the
+allocator log, not on that column.
 
 ## Not done yet