SAVEPOINT: END OF PREFILL BY DEFAULT — THE GOVERNOR'S MID-PROMPT WRITES ARE
ARMED BY EVIDENCE
==========================================================================
Branch feat/savepoint-end-of-prefill-default, off main b56978c84. The
predecessor is docs/receipts/savepoint-hot-path-2026-09-09.txt, which left the
shipped configuration at +1.16% / +1.22% of a cold 6300-token turn's TTFT
against the machinery's absence, with the bar at 1%, and had just falsified
the last launch-thread hypothesis (K=4 grouped spills: the same +1.21%).

THE NUMBER
----------
Deployed configuration (ARBI_SAVEPOINT_ENABLED=1 vs =0, nothing else set; the
ON arm at this branch's default ARBI_SAVEPOINT_CROSSING_WRITES=demand), tree
6a50dcab9, four boots OFF/ON/OFF/ON, 4 warm-up + 24 measured reps per boot,
n=48 per arm, 206 GPU 1, c=1, 6300-token prompt, 512-token reply, fresh
nonce per rep (ab_eop):

  cell                 OFF        ON         ON-OFF    95% CI            MDE
  turn 0 TTFT          1.2234 s   1.2296 s   +0.50%    [+0.37%, +0.64%]  0.19%
  turn 1 TTFT (reuse)  1.2916 s   0.1714 s   -86.73%   [-86.79, -86.67]  0.08%
  turn 0 decode, ITL   27.63 ms   27.64 ms   +0.04%    [-0.06%, +0.15%]  0.15%
    paired by token position (tools/savepoint/itl_ab.py, which lives on
    branch origin/lcmix-conformance, not on main), 184 positions,
    7788 ON / 16192 OFF gaps

Per-boot turn-0 means: OFF 1.2225 / 1.2243, ON 1.2301 / 1.2290. Share of the
interval below 1%: 100%; one-sided p(effect < 1%) = 0.000. PASSES the bar,
whole interval. Decode: no effect detected at an MDE that could have seen 1%.

Self-check, both ON boots identically: crossing_write_total{skipped_unarmed}
84 (three crossings per cold turn, none written), snapshot_total 56 (28
prompt-end writes + 28 turn-1 writes), snapshot_route_total{in_forward} 56,
resume_total 28. One prefill write per cold turn where there were four, and
the turn-1 resume is what it was.

Prediction stated before the run: ~+0.8%, on the reasoning that three of the
four writes' bookkeeping would go. It landed lower — +0.50% — so the per-write
cost was larger than the ~6.8 ms line the profile had attributed to it. Read
against the K=4 result (calls cut by three quarters, no movement) and the
4-5 us slot fence (the copies overlap), what the three writes took with them
is the per-write host work — the ring hand-out, the launch calls, the chain
digest, the put — not their bytes and not their launch count.

WHY THE WRITES WERE INSURANCE AGAINST A CASE THAT NEVER OCCURS HERE
-------------------------------------------------------------------
A crossing write — a whole recurrent state copied to host at each
chunk_prefill multiple inside the prompt — serves exactly one thing: a
DIFFERENT conversation that shares the prompt up to that crossing and
diverges after it (a shared system prompt). A conversation resending its own
history resumes from the prompt-end write and never touches one. The arm
measured all night is c=1, one conversation, fresh nonce per rep: nothing is
ever shared, and every crossing write was a premium on a hit that could not
happen. The earlier steer to keep them unconditionally came from a correct
observation (dropping them breaks shared-prefix resume; for a hybrid a KV
match without its recurrent half is discarded whole) and the wrong
conclusion from it.

WHAT WAS BUILT
--------------
ARBI_SAVEPOINT_CROSSING_WRITES = demand (default) | always | never.
  demand:  a tenant writes crossings only once a request in it has shown one
           would have served. always: every crossing from the first prefill —
           the behaviour before this flag, and its A/B arm. never: end of
           prefill only, whatever the evidence. Read once at scheduler
           construction, like the prompt-end flag, so the arming seam and the
           commit seam answer the same way for one step.

THE TRAP, AND THE SIGNAL THAT AVOIDS IT. A hit on a crossing write cannot be
observed while crossings are not written — nothing exists at 4096 for a
second conversation to match, so arming on hits would never fire and the
policy would sit permanently off looking correct. The demand is read as the
COUNTERFACTUAL instead, off two numbers the admission path already holds:
the radix walk's page-digest count (its reach into a stored prefix) and the
depth of the deepest savepoint it could resume from (the best match). A
governor line between the two is a crossing write that WOULD have served the
request. No store lock, no second walk, no probe_reach — the gate that kept
probe_reach behind isEnabledFor(DEBUG) stays. A request whose reach and
deepest savepoint sit in one governor span (a conversation resending its own
history) is not demand. Without the radix chain the reach is not known at the
match; there the KV match discarded for want of a savepoint
(hybrid_no_savepoint_fallback) is the same demand seen from the other side.

ONE PREDICATE, TWO SEAMS. The scheduler arms the forward's fold split only
for a crossing the tenant writes (savepoint_fold_split learned `crossings`),
and the commit asks the same predicate for the same step, so no forward ever
emits a state the commit then declines to label.

COUNTERS THAT CAN FAIL
  crossing_write_total{decision=skipped_unarmed | written, policy}
    every governor crossing a prefill step reached, and what the policy did
  crossing_armed_total{signal=reach_past_savepoint}
    every tenant armed, by the evidence that armed it (INFO line names the
    tenant, the reach, the depth and the governor)
  partial_match_lost_total{crossings=unarmed | armed}
    every request a missing crossing cost: unarmed is the policy's price,
    armed is a crossing that was wanted and still missing. Nonzero `armed` on
    a workload that shares prefixes says the arming is too slow — one
    conversation of lag is inherent (the arming conversation writes nothing
    itself; the next one writes; the third benefits).
  snapshot_skipped_total{reason=crossing_unarmed}
    the commit's own name for the skip.
Also fixed on the way: Mamba2's scan emits BEFORE its conv window is staged,
so it claims the staging fence ahead of its kernel (the fence used to land
after the emit had already written the slot).

COVERAGE UNDER THE DEFAULT: THE SHARED-PREFIX ARM
-------------------------------------------------
tools/savepoint/retention_scenarios.py --scenarios shared_prefix: eight
conversations opening with the same ~4050-token system prompt, two turns of
64 tokens, three passes per boot with a fresh nonce each (a pass is eight NEW
conversations sharing the opening), one conversation in flight at a time
(--max-inflight-tokens 4500), demand boot then always boot (shared_covseq):

  turn-0 cached%          pass 1 (mean/median/min)   pass 2         pass 3
  demand (the default)    84.3 / 94.8 / 0.0          94.8 / 94.8    84.3 / 94.8 / 0.0
  always                  84.3 / 94.8 / 0.0          94.8 / 94.8    84.3 / 94.8 / 0.0
  turn-1 (own history)    92.8 in every cell of both boots

Identical, cell for cell. The one 0.0 in pass 1 is the first conversation of
the boot (nothing stored yet); the one in pass 3 is one ring miss in 27
(hybrid_no_savepoint_fallback 1, the 16-slot ring at 43 overwrites) — the
same miss in both arms, and retention's, not the policy's. So the default
keeps the always arm's hit rate here — but read WHY before crediting the
arming: in this shape every conversation's prompt-end write lands at 3840,
INSIDE the shared opening, so the second conversation onward resumes from
the first's prompt-end write and the crossing at 2048 is dominated. The
shape where crossings decide the hit rate — a shared opening followed by a
LONG differing user turn, so that the prompt-end write lands past the
divergence and only a crossing inside the opening can serve the next
conversation — is not one the harness has; the demand rule's answer for it
is pinned by tests/test_savepoint_crossing_policy.py rather than by a card.

The first, concurrent shape of this run (eight conversations started at
once, shared_cov) is recorded because it misled for an hour: demand read
10.5% at pass 2 against always's 55.5%, and neither reached the 4096
entry. That shape measures two things that predate the policy — only one
prefill row's split can be armed per step, so eight prompts in the same
steps drop most of their crossing writes (snapshot_skipped{
fold_split_not_opened} 11-13, off_page 10), and the 16-slot ring wrapped
43-46 times in two passes — and, under demand, the writes only start after
the first evidence, so a pass where everything is concurrent writes about
half of what always writes and keeps less of it. Serialising the
conversations removed the confound and the two arms became identical.

WHAT THE RUN FOUND IN THE RULE. The demand boot armed on a request that was
NOT a different conversation: turn 1 of the first conversation, whose tree
walk reached 4096 (its own 64-token reply's page), whose prompt-end write
sat at 3840, and whose 64-token reply had crossed no decode-write page —
so the governor line at 4096 lay between reach and deepest entry and read
as demand. No prefill had ever crossed there; only the reply had. The rule
now excludes a request the tree matched to its own last page while it
holds an entry (reach == limit and usable > 0: a continuation, served by
the prompt-end write) and keeps a full match with NO entry as demand (a
prompt that is a proper prefix of a stored one has nothing to resume
from). A c=1 workload whose prompt length and reply straddle a chunk_prefill
multiple would otherwise have re-armed the crossing writes on its first
second turn, silently, and paid the premium the default exists to remove;
the A/B above (6300 + 512, decode writes at every page) did not happen to
straddle one. The regression test names the shape.

VALIDATION
----------
  tests/test_savepoint_crossing_policy.py (13): the seam under each policy
  and its counters; the arming and its counters; the same-span case that is
  not demand; the admission path reading the evidence without probe_reach
  (asserted: probe_reach is never called); the scheduler's arming seam
  agreeing with the commit seam over the CPU hybrid pool; the derivation.
  Tests about the write path itself now state the policy they run under
  (always), so the served default has its own tests rather than inheriting
  theirs.
  CPU lane, tests/ -n 4 in registry.arbi.work/arbi-serve:test-latest, CUDA
  hidden: tree 6a50dcab9 (the A/B's) 19500 passed, 386 skipped, 0 failed;
  the final tree (the demand rule's full-match exclusion) 19501 passed, 386
  skipped, 0 failed. ruff 0.15.21 check + format clean.
  Null control before the chain (smoke_eop, 2 cold turns): 6 crossings
  skipped, 4 writes, all in-forward, 2/2 resumes — the mechanism ran.

WHAT IS LEFT
------------
  * the remaining ~6 ms per cold turn (+0.50%): one write's bookkeeping
    (~2 ms by the earlier profile) plus what stays on every armed step and
    did not shrink at K=4 — the arming (~0.2 ms/step), the emit table, the
    conv gather, the reuse fence. Under the bar; not zero. The next honest
    lever is the per-write host path itself (ring hand-out, digest, put),
    measured per call rather than as a line.
  * a deployment that DOES share prefixes pays the crossings from the
    conversation after the first that wanted them; whether the one
    conversation of lag matters is what partial_match_lost_total{armed}
    reports there.
