e2e: accept Plex's session-less hand-off to app.plex.tv

The full-suite re-run after the reset fix came back "1 flaky": 12-crawl reached
plex.franksdank.cloud, the guard cleared, and Plex Web — signed out in the
qa-e2e profile — handed the browser to its own hosted sign-in surface, so the
hostname never settled on the vhost (60 s poll, Expected plex.franksdank.cloud /
Received app.plex.tv). settleThroughGuard now takes a HANDOFFS landing list per
vhost; only plex.franksdank.cloud gets one, every other host still has to land on
its own vhost, and the guard assertions (Anubis cleared, no authentik uidField,
status < 500) are unchanged. Worklog and E2E gotcha 6 carry both symptoms: the
ERR_ABORTED reset and the hand-off.

serverAppConfigs-docs/Architecture/E2E Suite.md

@@ -82,10 +82,14 @@ real IdP credentials.
 5. **Solve-once cookie.** Since Anubis v1.27.0 + `COOKIE_DOMAIN` (see
    [[Anubis]]), one PoW per fresh context covers every guarded vhost — crawl
    and SSO specs complete in ~0.5 s per vhost instead of a PoW each.
-6. **Apps navigate too.** `12-crawl` returns to the homepage between links, and
-   Plex Web (signed out, so it shows its own *"would like to sign in to your
-   Plex account"* iframe) keeps redirecting the top frame — Chromium cancels our
-   `goto("/")` with `net::ERR_ABORTED`, which used to abort the whole crawl
-   (once as a 420 s timeout, once at 5 s on the same link). `backHome()` re-issues
-   the navigation; the app itself was already judged, so the abort is the app's
-   behaviour, not a guard-chain failure.
+6. **Apps navigate too — and may leave.** `12-crawl` returns to the homepage
+   between links, and Plex Web (signed out in the `qa-e2e` profile) runs its own
+   sign-in flow: it redirects the top frame, so Chromium cancelled our
+   `goto("/")` with `net::ERR_ABORTED` (once as a 420 s timeout, once at 5 s on
+   the same link), and the same redirect then lands the browser on
+   `app.plex.tv` — Plex's hosted surface for a session-less client — which broke
+   the `hostname == target` law. Two narrow answers: `backHome()` re-issues the
+   navigation on that one error class, and the landing check takes an explicit
+   hand-off list (`HANDOFFS`) instead of a single host. The guard contract is
+   untouched: challenge cleared, no authentik `uidField`, status < 500, and every
+   host NOT in the list still has to land on its own vhost.

serverAppConfigs-docs/log.md

@@ -1954,3 +1954,52 @@ every restart since the cutover.
   thinking ×1.9. Bought: 7.4 GiB of RAM back as page cache for the table long
   prompts read, +12.6 % cold prefill, retrieval 18/18, the base checkpoint
   itself instead of the finetune.
+
+## 2026-10-17 — frank-dragoon: ceiling and pool cut to 200,704; crawl reset fix
+
+- Ask: lower frank-dragoon's context "to 196k". Settled on **200,704** for BOTH
+  `HALOGEN_CTX` and `HALOGEN_KV_POOL_POSITIONS` (49 × 4096 — the per-slot rung
+  frank-zealot runs; the card recommends pool == ctx, and that equality is where
+  the memory is). Nothing in the fleet needs the bigger window, and the v2
+  checkpoint serves anything up to its native 262,144.
+- Boot ledger (`7c4dbeb`, `status=deployed`): `reserving the KV pool, 200704
+  positions (about 5.5 GiB)`, `62.9 GiB of weights … 5.5 of KV pool, 5.7 of
+  working memory, 74.1 GiB in all`, prompt cache entries 111 MiB at the new ctx,
+  no clamp line. My arithmetic predicted 5.4/74 — the ledger is quoted instead.
+- Harness moved WITH the ceiling (400-zone law): `models.yml`
+  `contextWindow: 155648` = ceiling − 45,056; compaction now fires at 85 % =
+  132,301 est ≈ 136k measured, and the 180k compaction target of the 262,144 era
+  is unreachable because the window itself is smaller. `maxTokens` 45,056 and the
+  coupled cap/timeout 65536/7200 untouched. Worst-case harness request =
+  1.03 × est + min(45056, 151552 − est) ≤ 156.2k tokens vs the 200,704 ceiling.
+- Probes on the live endpoint: over the ceiling → `400 … it is 297109 tokens and
+  the context is 200704, 96405 tokens over` in 0.86 s (preflight rejects before
+  any prefill, so probing costs the endpoint nothing); harness-shaped admission →
+  122,679-token prompt with `max_tokens: 45056` (reservation 167,735) accepted,
+  81.1 s wall (≈1,513 t/s cold prefill), `27*59` answered **1593** from inside a
+  122k-token haystack, `finish_reason: stop`.
+- Seam re-keyed (`frank_dragoon_unit.bats`): the fit-law test now proves the
+  invariant at the new pair — `ctx ≤ pool ≤ slots × ctx` and
+  `harness window ≤ ctx − 45056` — so a future raise of one without the other
+  fails the gate. bats 371/371.
+- Deploy verdict: the endpoint dispatched healthy (`status=deployed`, `/health`
+  200), but the `[3/3]` Playwright gate failed on `12-crawl` and the deployer
+  correctly said **DEPLOY INCOMPLETE**. Root cause was NOT the endpoint — it was
+  Plex Web, signed out in the `qa-e2e` profile, running its own sign-in flow,
+  which broke the spec two different ways:
+  1. it redirects the top frame, so Chromium cancelled the crawl's in-loop
+     `page.goto("/")` with `net::ERR_ABORTED` — and that reset sat outside the
+     `try`, so one host aborted the whole crawl (once as a 420 s timeout, once at
+     5.4 s); fixed with `backHome()`, which re-issues on that one error class.
+  2. the same hand-off leaves the browser on `app.plex.tv` (Plex's hosted surface
+     for a session-less client), so the `hostname == target` law could never
+     settle — this is what the first full-suite re-run surfaced as `1 flaky`;
+     fixed with an explicit `HANDOFFS` landing list.
+  Plex itself was healthy throughout (container up 2 days; 32400 answers HTTPS
+  401 / plain-HTTP empty reply, which is what Plex Web authenticates against),
+  and the guard contract is still asserted for every vhost: challenge cleared, no
+  authentik `uidField`, status < 500. Both symptoms recorded as gotcha 6.
+- Cost of the cut: two maximum-length conversations never coexist (one
+  200,704-position pool behind both slots; two of ≤100k still do). Bought: 1.7
+  GiB back as page cache for the 47.68 GiB n-gram table — 9.1 GiB against the
+  2026-10-06 shape's 524,288 pool — and a smaller prompt-cache entry.