docs(halogen): record the measured arena model; the 65536 experiment was worth doing

Raising HALOGEN_MAX_TOK to 65536 did not shrink the pool, it OOMed the boot:
the arena alone (37.3 GiB) exceeds the 29.5 GiB device budget, so even the
minimum pool faulted and dmalloc failed at 39.97 GiB. Rolled back to 16384,
which restored the 524288 pool and a clean completion.

The three measured arenas are exactly linear in the flag — 3.80 GiB base plus
8.40 GiB per 16384 tokens, predicting all three to 0.1 GiB. That gives a real
sizing rule instead of guesswork, and it says the deployed 16384 is the
CEILING, not a conservative choice: 29.5 - 1.5 margin - 14.4 pool leaves 13.6
for the arena, i.e. max_tok <= 19,115.

The corner check falls out of the same model: set max_tok back to 32768 and
only 7.4 GiB remains for the pool, ~269k positions, which is precisely the
262144 config this host ran before. The two corners of the feasible box are
the only two points it has ever served.

No functional change — the quadlet edit is comments only; the running service
is already at 16384 from the rollback deploy (258cccb).

dankclaw/frank-large/quadlet/frank-large.container

@@ -107,13 +107,25 @@ Environment=HALOGEN_KV_SLOTS=4
 # LOAD-BEARING. This line is what makes the doubling above real; do not
 # "clean it up". The device budget here is 121 GiB - 67.7 resident weights
 # - 24.0 reserved for the n-gram page cache and the OS = 29.5 GiB, and that
-# one budget carries BOTH the KV pool and the prefill arena. At the upstream
-# HALOGEN_MAX_TOK=32768 the arena is ~20.6 GiB, so 524288 positions need
-# 35.0 GiB against 29.5 available and HALOGEN_KV_POOL_FIT silently lowers
-# the pool back to 262144 — the deploy still reports healthy, so the
-# regression is invisible unless you read the ledger. Halving the arena to
-# ~10.5 GiB brings the 524288 need to ~24.9 GiB, which fits with ~3 GiB
-# of margin, at about 8-9% of prefill throughput.
+# one budget carries BOTH the KV pool and the prefill arena.
+#
+# Measured across three restarts on 2026-09-12. The arena (the engine's
+# "everything but the pool" figure) is linear in this flag: 3.80 GiB of base
+# plus 8.40 GiB per 16384 tokens.
+#   16384 -> arena 12.2, 524288 needs 26.6 -> FITS
+#   32768 -> arena 20.6, 524288 needs 35.0 -> fit lowers the pool to 262144
+#   65536 -> arena 37.3, even 262144 needs 44.5 -> OOM, dmalloc FAILED at 39.97
+# So 16384 is not conservative, it is the ceiling: 29.5 budget - 1.5 margin -
+# 14.4 pool leaves 13.6 for the arena, i.e. max_tok <= 19,115, and 16384 is
+# the largest power of two under that. The reverse checks too — put max_tok
+# back to 32768 and only 7.4 GiB is left for the pool, about 269k positions,
+# which is exactly the 262144 config this replaced. Those two corners are the
+# only points of this box that have ever run here.
+#
+# Do NOT raise this flag past 16384 while the pool stays doubled: 65536 does
+# not shrink the pool, it stops the server booting at all — and the unit still
+# reads active with the container "Up (starting)", so the health check waits
+# out LLM_WAIT rather than failing fast.
 Environment=HALOGEN_MAX_TOK=16384
 # RAM left for the n-gram table the engine reads through the page cache.
 # Above the vendor's 20 because a dozen containers share this host; too low