loopd: the tag check asks /tokenize twice, not once per tag

Found in the M5b device check on straylight: the self-test asked about
each of the 33 tags and each neutralised form, 66 requests, one
connection each, and inferproxy's token bucket (burst 10) refused the
ninth, so loopd would not start. Now it asks about all the tags at once,
one per line, and then all their neutralised forms: the answer to the
first must hold each tag's recorded token in order, the second none of
them. Each tag is a special token, split out before anything else, so
the lines between cannot change it; and a neutralised form is only
dangerous as a tag's own token, so that is what the second answer must
not hold. The errors name a tag by its id, as before.

The fake tokenizer reads text with several tags in it; the tests cover
each tag as ordinary tokens, as another listed or unlisted token, a
duplicated token in the middle and at the end, a form holding each tag,
and both requests failing. Spec section 8 and the runbook entry follow.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs/specs/2026-09-26-m5b-hardening.md

@@ -239,9 +239,12 @@ are what every later request replays and the inference contract holds:
 The model's own output (reasoning, content, tool calls) is not touched: it is logged and replayed
 exactly as the server returned it.
 
-**The self-test** gains a fourth check, run at startup before `loopd` serves anyone: for each tag in
-the list, the server's `/tokenize` must give one token for the tag, and more than one for its
-neutralised form. If either fails, `loopd` does not start, with a new runbook entry. This catches a
+**The self-test** gains a fourth check, run at startup before `loopd` serves anyone: asked about
+every tag in the list at once, one per line, the server's `/tokenize` must give each tag's recorded
+token, in order; asked about every neutralised form, it must give none of those tokens. If either
+fails, `loopd` does not start, with a new runbook entry. Two requests, not one per tag: the device
+check (2026-09-27) found that 66 requests, one connection each, overrun `inferproxy`'s burst of
+ten connections. This catches a
 list entry that no longer works after a model or template change; it cannot find a tag missing
 from the list, because the server does not list its special tokens.