#1777 serve: reasoning loop recovery also catches a loop written as one long word (#1753)

本文

Fixes #1753.

**What it changes:** reasoning loop recovery (opt-in, #728) now also checks the last 2,048 chars of the reasoning for a period of at most 64 chars, before the word count. A periodic tail reads as coverage 1.0, so both `stop` and `recover` act on it. This is the shape #1753 replayed: a greedy run that writes its loop as one long word (a 24k-digit string cycling the 11-digit pattern 58747693387) is a single word to the 2,000-word window, and it never repeats one token because the tokenizer has no multi-digit tokens, so both guards passed it and the run burned the whole reasoning budget (24,599 and 32,791 tokens in the captured runs, both answering 1).

**What it leaves alone:** the word count, its thresholds, the check cadence and the recovery splice are unchanged, and the check runs only when `reasoning_loop_recovery` is on, so the default path is byte-identical. No engine change. The issue's engine-level variant (extending #606 to short periods) would also protect users who have not opted in; this PR is the server-side half and uses the exact 2,048-char / 64-period window the issue author replayed across 70 captured reasonings (both digit-string runs caught, zero false fires).

**How I checked:** `python -m unittest serve.test_reasoning_loop_recovery`, 18 tests, all pass. New tests cover the issue's cases directly: the digit cycle scores 1.0, a non-periodic 2,893-char digit string scores 0, a 1,100-char tail too short to judge scores 0, and a stop-mode run with MockEngine whose script is the digit string now ends at 2,560 tokens instead of running to the budget. Also ran the full serve suite (595 tests): the 8 errors there also error on an unmodified clone (they need the real tokenizer files and Windows job objects), nothing else changed. CPU only, no GPU involved.