fix(tests): site the 18 remaining store roots off the contended disk, and census the set

[ZacxDev]

The siting gap

tekton/devrc-pytests intermittently fails
test_subsystem_store_api.py::TestARefusedWriteIsIndistinguishableFromAnAbsentOne::test_POSITIVE_CONTROL_the_APPEND_comparison_CAN_see_the_difference,
including on docs-only PRs. The mechanism is already diagnosed in
scripts/ci-repro/README.md: server.py:_replace_bytes fsyncs the file and then its
parent directory inside the request, before the response is written; under disk
contention on the single node devrc-ci is pinned to, one fsync exceeds HANG_TIMEOUT
(60.0) and the client raises TimeoutError. The suite's own classifier says so
unprompted: MECHANISM = SERVER_BLOCKED_IN_FSYNC.

A fix for that shipped in #1211 / #1219 / #1239 — scripts/testlib/store_siting.py's
store_root(tmp_path), which sites the store on tmpfs when one is usable and falls back
to tmp_path otherwise. It was never applied to the site that fails.

At origin/main this file had 5 call sites of store_siting.store_root and 18
that open-coded tmp_path / "store". The failing class was one of the 18: its _phases
helper built root = tmp_path / "store", unsited, on disk unconditionally.

Why that one test and not its siblings: within the class, test_POSITIVE_CONTROL_… is
the only test that gets a 200 appended. The others all assert a 404 — refused or
absent — which is answered before any write and never reaches _replace_bytes. So it is
the only test in the class that executes the two in-request fsyncs.

Corroborating, from the CI traceback already recorded in ci-repro/README.md: the
stalling write targets
/tmp/nix-build-devrc-pytests.drv-0/pytest-of-nixbld13/pytest-0/popen-gw3/…/store — a
tmp_path-derived path, not a devrc-store-* tmpfs holder.

What this changes

1. All 18 open-coded sites now take their root from a sited_root fixture —
store_siting.store_root with a test's lifetime.

A fixture rather than 18 inline with blocks, and the reason is lifetime, not
convenience. Several of the sites build the root inside a helper whose return value
is used throughout the test body: _phases returns a pair of present()/absent()
closures, _entry_path and _twin_heading_entry return a path. A with wrapped around
the helper call tears the store down before a single assertion runs. A with wrapped
around each whole test body is 30 blocks of re-indentation — which is the exact shape of
the scripted conversion this repo already reverted once (it "silently skipped 9 of 19
signature edits while its own assertion still passed", per the ledger's own comment).
Taking the context manager as a fixture makes its lifetime the test's, per site, with
nothing to get wrong per site.

The one behaviour difference from an inline with is written into the fixture rather
than glossed: store_root skips its budget check when the body is raising, and pytest
does not throw a test's failure into a fixture generator, so on this path the check runs
even for a failing test. That is already true of store and scoped_store — it is the
standing cost of the idiom here, not something introduced by this change.

2. The guard is widened from one fixture to a census.

test_store_siting_ledger.py already carried an AST ratchet, but as a count:
_DISK_ROOTED_SITES = 33. A count cannot distinguish "one site was migrated and one new
one was written" from "nothing happened", and its own history is a string of arguments
about whether the number moving meant new debt or a wider predicate.

It is now an enumerated set: _DISK_ROOTED_ALLOWLIST, keyed
<Class.function> :: <unparsed expression> (never a line number — that moves when an
unrelated docstring gains a sentence), each entry carrying its reason.
test_the_disk_rooted_census_matches_the_allowlist_EXACTLY asserts set equality in both
directions, and names the offending site in the failure message.

15 entries remain. They are the population that was never spelled "store" — served,
served-elsewhere, stage, absent, big, at-the-cap, unambiguous — and every one
was checked to issue no write verb (no post_bullet, no create_put, no
method="PUT"/"POST"), so no request reaches _replace_bytes and nothing fsyncs inside
a request. They are still disk-backed, and that is recorded rather than hidden: siting
them is the obvious follow-up, deliberately not folded into a change scoped to the
write-path sites that were failing the gate.

A second arm, _SITED_STORE_ROOT_CALLERS, pins the other side of the relationship — the
set of store_siting.store_root(...) callers — so a deleted siting is red too. The
mutation matrix below shows that arm is not redundant.

The existing behavioural positive control is kept, and its class docstring is corrected.
It claimed a fixture falling back to disk "EVERYWHERE" would be caught, while its control
took one fixture (store). That is one site wide; 18 further roots sat behind that
green, including the failing one. sited_root now has its own behavioural control.

Red before green

scripts/ci-repro/slowfsync.c gains an opt-in SLOWFSYNC_SKIP_TMPFS=1 mode, because
the default mode cannot measure a siting fix: it interposes on fsync(2) in libc, so
it stalls tmpfs too, and both arms of the comparison go red. Measured:

default mode, fd on ext4   -> stalls 65.0s (fs magic=0xef53)
default mode, fd on tmpfs  -> stalls 65.0s (fs magic=0x1021994)

The new mode passes a TMPFS_MAGIC fd through without consuming the one-shot latch
(a pass-through that spent it would turn "the store moved to tmpfs" into "the shim ran
out of ammunition"), and a failing fstatfs() stalls rather than skips. Default
behaviour is unchanged, so every measurement already in ci-repro/README.md still holds.

All rows below are the same single test, -s so the shim's own stderr is visible:

tree	shim mode	store lands on	result
origin/main	none (control)	ext4	whole class 5 passed in 8.76s
origin/main	default	ext4	1 failed in 65.52s, TimeoutError at socket.py:720, MECHANISM = SERVER_BLOCKED_IN_FSYNC, stall at _replace_bytes:2073 os.fsync(fh.fileno())
origin/main	SKIP_TMPFS=1	ext4	1 failed in 63.96s, same, stall line fs magic=0xef53
this branch	SKIP_TMPFS=1	tmpfs	1 passed in 3.67s, exactly two pass-through … magic=0x1021994 lines (the file and its parent dir — _replace_bytes's pair), latch untouched
this branch	default	tmpfs	1 failed in 63.69s, stall line fs magic=0x1021994
this branch	SKIP_TMPFS=1, siting forced to fall back	ext4	1 failed in 64.29s, stall line fs magic=0xef53

The last two rows are what make the fourth mean anything, and they are different claims.
Row 5: the shim can still kill this test on the branch, so the green is not "the
reproducer no longer reaches this code". Row 6: forcing store_siting.tmpfs_dir() to
None reproduces main's red exactly, so the green is the siting and not some other
edit on the branch.

The origin/main rows were taken with test_subsystem_store_api.py,
testlib/store_siting.py, test_store_siting_ledger.py and server.py byte-identical
to origin/main (only slowfsync.c differed). Those four files are also identical at
fbc4dd39 and at the current base 50b384c0, so the baseline holds for both.

Mutation of the census guard

Run with __pycache__ cleared between mutants (a same-length edit inside one second is
invisible to CPython's mtime-in-seconds + size cache and scores SURVIVED without running):

mutant	census	sited ledger	others, THIS FILE ONLY
a migrated test reverted to tmp_path / "store"	RED, naming that exact test	green	22 passed
sited_root de-sited to tmp_path / "store"	RED	RED	21 passed
sited_root de-sited to tmp_path / "holder"	green	RED	22 passed

Each died on its own message, not on some other test's error. The census message
reads:

AssertionError: these disk-backed store roots are NOT in _DISK_ROOTED_ALLOWLIST:
  TestTheLoaderRefusesHostileEntriesByKind.test_a_CLEAN_store_is_UNCHANGED_by_the_guard :: tmp_path / 'store'   (line 13749)

Mutant 3 is the one that earns the second arm: a de-siting inside a fixture, under a
directory name outside _ROOT_NAMES, is invisible to the census — its flow arm stops at
the fixture's scope boundary, its on-sight arm only recognises store/src — so
_SITED_STORE_ROOT_CALLERS is what catches it. It also falsified my own first draft of
that comment, which had claimed the blind spot was "a fixture" — mutant 2 shows it is
narrower than that.

🔴 CORRECTED: this said _SITED_STORE_ROOT_CALLERS catches mutant 3 "only", and that
is false wherever a usable tmpfs exists. The others column above is a one-FILE
run of the 23-test ledger module, so "every other guard in both files green" was
extrapolated from a measurement that never opened the other file. Re-run over BOTH
files on a tmpfs host, mutant 3 gives 2 failed, 781 passed:

FAILED test_subsystem_store_api.py::TestTheStoreIsSitedOffTheContendedDisk::test_the_sited_root_fixture_ACTUALLY_lands_on_tmpfs_when_one_exists
FAILED test_store_siting_ledger.py::test_the_SITED_store_roots_are_a_pinned_ledger_too

The behavioural control reads the fstype of sited_root.parent and finds the disk. The
census stayed green, so the blind spot itself is re-confirmed by the same run.

The arm still earns its place, for a narrower reason than "only": the behavioural
control SKIPS where there is no usable tmpfs — absent, not tmpfs, under
_MIN_FREE_BYTES free, or unwritable — which this PR says the gate may well be. So the
true claim is the only guard that can see it on a machine with no usable tmpfs, and
that is now what the failure message and the comment above the set say.

Also re-measured — and a claim of mine that the measurement falsified

_ROOT_NAMES's comment said seven sites were counted only by the on-sight
directory-name arm, and named them. All seven were among the 18 migrated. Re-measured by
running the census with _ROOT_NAMES = {"store", "src"} and again with it empty:
15 both times, identical keys — it contributes nothing on this file now.

My first replacement comment then said it was kept because "two of this file's own probe
tests depend on the on-sight arm", naming
test_the_site_index_does_not_key_on_the_DIRECTORY_being_spelled_store. That was
false, and running it is what showed it: every probe in that test hands its path to
running(...), so the flow arm counts it and the spelling never decides anything.
Measured by setting _ROOT_NAMES to empty and running every argument-free test in the
module — zero behaviour changes.

So the comment now says the true thing: the set is inert everywhere that is measured
today, it is kept on an argument (the flow arm's _ROOT_CONSUMERS closes renames but
not growth into a new consumer name, and the on-sight arm is the only path that does not
go through that set), and the closing condition for deleting it is named. The
contribution is now measurable in one command instead of asserted in prose, which is what
caught the false sentence.

Gate

Authoritative tier — the one Tekton runs, nix build .#checks.x86_64-linux.pytests,
on this branch rebased onto 4e26ec9a:

RESULT: PASS (exit=0)      NIXBUILD_RC=0
86 per-target result lines, 0 of them FAIL
  PASS  scripts/tests             (collected=13587 passed=13587 skipped=0 floor=13026)
  PASS  scripts/dl-router/tests   (collected=1020  passed=1020  skipped=0 floor=942)
TOTAL collected=21716  passed=21714  skipped=2  failed=0  (floor 20441 = sum of 28 per-target floors)
grep 'panic: test timed out' -> 0

Counted from the runner's own per-target lines, not from an exit code. The 2 skips are
the pre-existing pinned real-Postgres ones; scripts/tests skipped 0, which means
both tmpfs behavioural controls — the existing store one and the new sited_root one —
ran rather than skipping. /dev/shm is usable in the nix sandbox.

Node tier, nix build .#checks.x86_64-linux.nodetests, built separately (never
concurrently with the pytest one — a combined invocation contends on the nix store and
produces false failures): RESULT: PASS (exit=0), NIXBUILD_RC=0, # fail 0 on every
suite. This diff touches no JS; the run is here because "both tiers" is the standing rule,
not because it could have been reached.

Dev-host tier, scripts/gate.sh --tier pytest: inconclusive, and I am not counting
it as a pass. It got through scripts/tests (13519 passed, no failures) and then the
runner was SIGTERMed at ~65 min, so it printed RESULT: FAIL (exit=143) — a killed run,
not a test failure. That run also showed one failure in
scripts/dl-router/tests/test_store.py::test_six_writers_with_a_tiny_busy_timeout_still_land_every_row
(OperationalError('database is locked') against a deliberate 5 ms busy_timeout).
That test is unreachable from this diff, and the discriminating control is above: the
same file, same test, 1020/1020 passed in the sandbox tier. A second agent was
running a full run-tests.sh in ~/workspace/devrc-gate-base concurrently, which is
exactly the load-contention flake CLAUDE.md already documents for dl-router SQLite.

Not verified

• CI itself. Everything above is measured on the dev host, where /tmp is ext4 and
  /dev/shm is tmpfs. The gate's sandbox may have no usable tmpfs, in which case
  store_root falls back to disk by design and this changes nothing there.
  store_root's docstring enumerates the five ways that happens.
• The 15 allowlisted sites are argued to be write-free from their call graph (no
  write verb reaches them), not from a runtime trace.

[ZacxDev]

Round 1 audit — 6 findings, all fixed

Round 0 (requirements & deletion) and round 1 (the nine axes) were run blind of each other, read-only, in separate worktrees.

Round 1 verdict: safe to merge, nothing deploy-blocking. Every finding was in the scaffolding, and all six were one shape: the guard's description is wider than the guard — the same class this PR exists to fix, recurring inside the fix.

What round 1 re-verified and found sound: 18 → 0 by AST (total tmp_path / X 142 → 124, an exact 18 drop, so nothing re-added under another name); all 15 allowlisted sites read individually and confirmed write-free; row 6 of the matrix load-bearing (forcing tmpfs_dir() to None reproduces main's red, so the green is the siting); teardown does not mask a real failure.

Round 0 ledger: round 0 · requirements: 9 (unattributed: 3) · deletion candidates: 3.

Queued follow-ups, deliberately NOT in this PR

1. Delete _ROOT_NAMES — measured inert three times independently (emptied set → identical pass counts and an identical census key set), including under the widened predicate. Kept on an argument, not a measurement.
2. Site the 15 allowlisted entries and drop the allowlist — a 33-site conversion is the shape that got reverted before, so not folded in here.
3. Question the layer (round 0, R1). The failing write lands on the step container's ephemeral /tmp; the CI task sets no TMPDIR and mounts nothing there. A medium: Memory emptyDir at /tmp would site every tmp_path in the suite in one infra change and retire this scaffolding layer as a flake defence. Not asserted to work — where the daemon build's /tmp resolves was not measured. Infra repo, operator call.

Not measured

Nothing here ran in the gate's own environment. If the CI container has no usable tmpfs, store_root falls back to disk by design. Checkable from any failure log: devrc-store-* = sited, pytest-of-* = fell back.

1. F1: `_is_disk_rooted_store_expr` no longer gates on the right operand being `ast.Name`/`ast.Constant`; `_used_as_a_store_root` alone decides, so an f-string/concat/method-call spelling of a write-path store root is now censused.
2. F1: claimed no-op on today's tree — old vs widened predicate over all 184 `test_*.py` in `scripts/tests` yields 221 identical keys, and the ledgered-file census is unchanged at 15.
3. F2: the "enumerate EVERY store site in this file" claim is removed; the bullet and the census docstring now state the predicate's actual reach and enumerate all three residual classes.
4. F3: "the ONLY guard that can see it" is rescoped to "on a machine with no usable tmpfs", in both the failure message and the comment, and the PR body's mutation table is relabelled `others, THIS FILE ONLY` with a CORRECTED block.
5. F4: `SLOWFSYNC_SKIP_TMPFS` compares its VALUE rather than testing presence, so `=0` disables the mode instead of enabling it.
6. F5: both the census and the sited ledger loop `EXPECTED_SERVER_TESTS` instead of hardcoding one file; keys gained a file component and remain qualname-based, never line numbers.
7. F6: the census positive control gained a second probe under a directory name outside `_ROOT_NAMES`, so the flow arm is exercised by its own control.
8. `_ROOT_NAMES` was NOT deleted and the 15 allowlist entries were NOT touched — both deliberately out of scope for this round.

[ZacxDev]

Round 2 delta re-audit — all 8 round-1 claims hold; 3 new findings, all fixed

Round 2 ran blind of the fix author, against d4e6afaf..157cd02e. All eight claims verified, four re-derived to the digit (221/221 keys over 184 files; census 15/0/0; mutant 3 → 2 failed, 781 passed; 16 SLOWFSYNC_SKIP_TMPFS spellings). Claim 8 — a negative claim — checked byte-for-byte: keys and reason strings identical.

Claim 4 was verified at both points of the tmpfs dimension, which is what makes it a claim rather than an assertion: with tmpfs forced unusable, both behavioural arms SKIP and the structural ledger still fails.

Authoritative tier at the head, read by content: scripts/tests collected=13587 passed=13587 skipped=0, TOTAL collected=21716 passed=21714 skipped=2 failed=0, RESULT: PASS.

The finding that mattered

The operand-type widening shipped with no regression test — restoring the exact pre-round-1 isinstance gates left the ledger at 23 passed. Every existing probe used an ast.Constant operand, so nothing exercised a JoinedStr/BinOp/Call/Subscript operand in either direction. A hand measurement in a commit message, in the module whose premise is that a hand measurement is not coverage.

Now pinned by test_the_operand_NODE_TYPE_is_not_what_decides_either — four non-Constant spellings across both arms, each twice (flowing into _build_store → must count 1; flowing nowhere → must stay 0). Watched red three ways: both gates restored → 1 failed, 23 passed; flow gate defaulted to True → the negative half fails on its own message; unmutated → 24 passed. Re-verified independently with a narrower mutation (one arm's gate only, isolating the guard from its sibling condition) — still the only failure, still its own message.

Ledger

round 2 · payload lines changed THIS round: 24 (since round 1: 24) · elapsed: 36m

Classification declared at round 1 and unchanged: test_subsystem_store_api.py PAYLOAD (revert test), test_store_siting_ledger.py and ci-repro/** SCAFFOLDING. Round 2 correctly notes all 24 sit inside a class docstring, so by executable payload the round changed 0 — recorded, but the measure is not being switched mid-ladder.

Still queued, still not in this PR

_ROOT_NAMES deletion (measured inert four times, including under the widened predicate) · siting the 15 allowlisted entries · round 0's R1, the CI /tmp tmpfs mount that would retire this scaffolding layer entirely (infra repo, operator call) · widening _assignments — not the trivial follow-up it looks like: the container-element half has no statically resolvable base for stores['a'], and closing either half changes the census over the real files, forcing a re-record of the allowlist in the same commit.

1. F7: `test_the_operand_NODE_TYPE_is_not_what_decides_either` pins the operand-type widening with four non-Constant spellings across both the `/` and `.joinpath` arms, each present twice — counted when it flows into a consumer, 0 when it flows nowhere.
2. F7: the predicate docstring no longer cites `test_a_path_that_is_never_used_as_a_store_still_does_NOT_count` as the control for the widening; that test's probes are Constants and cannot see it.
3. F8: the residual enumeration gained a fourth hole — a root reaching a consumer in one scope through a container element, a `for`/comprehension target, or a closure — with the measured numbers, applied at five sites rather than the one reported.
4. F8: `_assignments` was NOT widened; the enumeration was corrected instead.
5. F9: every residual bullet now leads with `PINNED` or `ONLY WRITTEN DOWN`, at both places the enumeration appears; one of four holes is guarded.
6. F9: the false "each pinned by a named guard over there" clause is removed from `test_subsystem_store_api.py`.
7. `_ROOT_NAMES`, the 15 `_DISK_ROOTED_ALLOWLIST` entries, and `_assignments` were all left untouched this round, deliberately.

[ZacxDev]

Round 3 delta re-audit — and the ladder STOPS HERE

All seven round-2 claims verified. Two were checked structurally rather than by eye: with docstrings stripped, the payload file's AST is byte-identical across the range (100659 → 100659 lines, against a positive control that can see a one-token change), and the ledger's is +169/−0 with the whole addition being the new test function. So "_assignments not widened" and "_ROOT_NAMES/allowlist untouched" are proven, not asserted.

The new guard came out stronger than it claimed. Eight mutants: each arm is independently covered (restoring either type gate alone names exactly that arm's probes); the negative half is genuinely reached, not short-circuited; and it goes red — not green — when the flow gate dies or _ROOT_CONSUMERS is narrowed. Emptying _ROOT_NAMES leaves it at 24 passed, which removes the one confound in the fixture design.

The fifth-shape hunt came back clean, and that is a result: 27 concrete shapes measured against the census's five failure mechanisms — sibling-method via self, pass-through helper param, functools.partial, .append-then-subscript, star-unpack, with-as, module-scope global, two-hop container, and the rest. No fifth hole. The enumeration is complete at the mechanism level; what was wrong was which mechanism the prose blamed.

Round 3's four findings — all fixed in 784d2651..30aa044b

One defect at several reader-facing sites: residual bullet 4 mis-attributed the mechanism behind a measured zero. The fix round re-derived the attribution one-at-a-time (monkeypatching _assignments and _path_base separately — reading the code cannot attribute a mechanism):

probe                          shipped  +assign  +base  +both
inline (control)                     1        1      1      1
dict element                         0        0      1      1
list element                         0        0      1      1
for target                           0        1      -      -
comprehension target (isolated)      0        1      -      -
closure                              0        0      0      0

So: widening _assignments closes 2 of 5, not "them" — the element rows are _path_base's and the closure is _walk_scope's. The definition sentence named two conditions where the code has three (_path_base must be able to name a base). And one of my own framings was wrong and the fix round refused it with measurement: row 5 is not "doubly-blocked" — +base alone takes it 0→1, so the subscript is sufficient and the comprehension target was never load-bearing there. The row was replaced with one that isolates the target rather than described as something it is not.

The fix round also caught and corrected its own error in commits 1–3 (it had written the reader's sense of "one function scope" into a sentence defining the code's), and deleted rather than reworded a count it could not verify from the tree.

🔴 Why the ladder stops here, stated explicitly rather than left implicit

The findings-keyed rule would run a round 4. I am stopping on the stated criterion instead, and naming why the rounds will not stop on their own:

• No 🔴 in any round. Zero deploy-blocking findings across three rounds.
• The entire remaining blast radius is "the document mis-states which line of code causes a measured zero." Nothing outside docstrings.
• The recurring shape was swept at every site, not the one reported — F10 at 3 sites, F13 at 2, F11/F12 at their own, plus the serve_store count.
• The attribution gate is structurally inert here. Rounds 2 and 3 each changed zero executable payload lines by AST measurement, while the by-file count reads 78 — because docstring lines in a payload file still count as payload. The gate cannot fire on a ladder that has moved entirely into prose.
• Each round's replacement sentence has become the next round's finding, repeatedly. That is the non-terminating shape, and the round-3 auditor reached the same conclusion independently: "neither is worth a round 4, and I would not run one."

What is deliberately left UNFIXED — open, not absent

1. _ROOT_NAMES is inert — measured four times independently, including under the widened predicate. Kept on an argument, not a measurement. Deletion is a queued follow-up.
2. The 15 _DISK_ROOTED_ALLOWLIST entries stay on disk. All 15 were read individually and confirmed write-free, so none reaches _replace_bytes. Siting them retires the allowlist entirely — a 33-site conversion, which is the shape that got reverted once already.
3. _assignments is not widened. Not the cheap follow-up it looks like: the container-element half has no statically resolvable base for stores['a'], and closing either half moves the census over the real files, forcing a re-record of the allowlist in the same commit.
4. Round 0's R1 — the layer question. The failing write lands on the step container's ephemeral /tmp; the CI task sets no TMPDIR and mounts nothing there. A medium: Memory emptyDir at /tmp would site every tmp_path in the suite in one infra change and retire this entire scaffolding layer as a flake defence. Not asserted to work — where the daemon build's /tmp resolves was never measured. Infra repo, operator call.
5. scripts/ci-repro/slowfsync.c has no automated build or lint anywhere. Its evidence is hand-run and does not recur; a future edit breaking it is undetectable until someone next needs it.
6. AsyncFor appears in the _assignments docstring's description of what widening would add, but only for and comprehension targets were measured.

🔴 And the thing a green gate here does NOT establish

A green gate on this PR is not the verifier. The gate validating a gate fix is not independent evidence, and one green cannot separate "the fix worked" from "this run would not have flaked". The verifier is the flake rate against a fresh baseline whose PR heads postdate the merge — claudedocs/handoff-gate-flake-store-api.md rank 1.

Nothing in three rounds was measured in the gate's own environment. If the CI container has no usable tmpfs, store_root falls back to disk by design and this changes nothing there. That is checkable from any future failure log without re-deriving anything: devrc-store-* = sited, pytest-of-* = fell back.

Round 0 trial record: ran: 1 · changed the outcome: 1 — weakly. It did not change the merge decision; it produced two items no correctness axis generates (an inert guard, and a requirement that belongs in another repo).

1. F10: the census definition sentence names a third condition — the expression must be one `_path_base` can name a base for — at all three sites that state it.
2. F11: `_assignments`' docstring carries the per-row table and says widening closes the `for` and comprehension-target rows only, leaving the two element rows and the closure open.
3. F12: residual bullet 4's row 4 is now an isolated comprehension target that moves 0→1 under a widened `_assignments`; the replaced row and the reason are recorded in place.
4. F13: the closure is attributed to the scope walker, not to a binding form, at both sites that had it under "one function scope".
5. The `serve_store` occurrence count is replaced by the property that matters — both occurrences are prose and no test runs it.
6. The census bullet's preamble says "within one TEST FUNCTION", naming why the reader's sense of "one function" and the code's come apart.
7. `_ROOT_NAMES`, the 15 allowlist entries and `_assignments` itself were left untouched, again and deliberately.
8. LADDER CLOSED on the stated criterion, not on a clean round — rationale above.

[ZacxDev]

Gated on the MERGED tree — both tiers green, and the red CI is attributed

Picked this up from rank 1 of handoff-alert-recall-and-skill-consumers (talos-infra#1488). The
rank asked for exactly this work; the open-PR sweep found it already done here, so this is a gate

• verification pass rather than a second implementation.

Merged tree — origin/main 2a4fe326 + this PR, clean ort merge. Sandbox tier (the one
Tekton runs), derivations built ONE AT A TIME:

• pytests PASS — collected=21958 passed=21956 skipped=2 failed=0, SCOPE: FULL (28 of 28 hermetic target(s)), RESULT: PASS (exit=0), NIXBUILD_RC=0
• nodetests PASS — TOTAL suites=5 files=41 tests=1449 pass=1449 fail=0 (floor 1367),
  RESULT: PASS (exit=0), NIXBUILD_RC=0

⚠ The dev-host tier (scripts/gate.sh) was not run on the merged tree.

The red tekton/devrc-pytests on this PR head

test_the_subset_note_reports_N_of_the_FULL_set_not_N_of_N — not reachable from this diff. It
lives in test_run_tests_targets.py and spawns run-tests.sh as a subprocess against
scripts/collector/i3/tests; this PR touches test_subsystem_store_api.py,
test_store_siting_ledger.py and two ci-repro/ files. It passes on current main on the dev
host (1 passed), and it passed on the merged tree above.

It is a distinct flake family from the fsync one this PR fixes, and the population is
measurable: surveying the 45 most-recent PRs, four failed tekton/devrc-pytests on a test in
test_run_tests_targets.py, each on an unrelated diff — #1429
(test_the_SUMMARY_BANNER_names_the_real_selection_source), #1450 and #1466 (both
test_a_partial_run_is_declared_where_gate_sh_actually_LOOKS), and this one. Every member of that
family shells out to a real run-tests.sh run, which is the shape that gets load-sensitive in the
sandbox. Worth its own guard eventually; it is not this PR's.

The closing condition, checked with an instrument independent of this PR's own census

An AST scan at class scope over test_subsystem_store_api.py, counting classes that build a store
and issue a write verb (so they fsync inside the request):

tree	store-building classes	raw and writing
origin/main	sited 1, raw 6	2 classes / 16 test methods
merged with this PR	sited 7, raw 0	0

And the guard was watched to go red. In a cp -a copy with .git removed and
PYTHONDONTWRITEBYTECODE=1:

• control, unmutated: 24 passed
• mutant — one sited site reverted to tmp_path / "store"
  (TestRefusedIsIndistinguishableFromAbsent.test_RECALL_…): KILLED, 1 failed, 23 passed,
  by test_the_disk_rooted_census_matches_the_allowlist_EXACTLY with its own message naming
  the exact site and line — not by a different guard's error, and not by the happy path resolving.

That is the half a per-file ledger could not do: before this PR, the same mutation passes, because
test_every_ledgered_file_IMPORTS_AND_CALLS_the_shared_siting_at_least_once only asks whether the
file uses store_siting anywhere.

Why this mattered — the concrete payout

devrc#1435's red CI was TestARefusedWriteIsIndistinguishableFromAnAbsentOne::test_POSITIVE_CONTROL_the_APPEND_comparison_CAN_see_the_difference
— one of the 16 above, and the handoff's leading hypothesis was the _free_port() TOCTOU. That
hypothesis is wrong: the test drives the server through running(), which builds it in-process
with port=0 and never calls _free_port(). It was the fsync mechanism this PR removes. The same
test also failed CI on #1434 and #1447.

⚠ Scope note on the reason strings: the allowlist's "read-only" entries claim no write verb reaches
_replace_bytes, which is the fsync mechanism specifically — not that a disk-backed root is
harmless. The PR says this itself; repeating it because it is the sentence most likely to be
compressed into "covered".