Changes touching this path

• loot lane new stops paying the whole lane board to print the one row whose id it already holds: lane_views filtered after lane_statuses had finished sweeping, and that sweep does a full DagRepo::load_from, a read_tree_at over a FOREIGN working root and an owner read per registered lane, so a spawn cost N graph loads and N whole-tree walks and then discarded all but one. It now resolves the spawned id directly through a new Workspace::lane_status, which reaches read_lane_entry - literally the per-id call list_lane_entries loops - and shares one row derivation with the board through two extracted helpers, so the two answers cannot drift. tree_walks goes N to 1 at every size measured (3 to 1, 7 to 1, 13 to 1), and policy_loads tracks it identically because both are one per read_tree_at; the spawn path itself contributes zero walks, which is why the before was exactly N rather than N plus something. The pin asserts CONSTANCY across three registry sizes rather than any numeric target, because a literal is the wrong shape for a claim about a slope, and it carries two controls rather than one for a reason that was found by experiment and not by taste: blinding the fixture so it registers nothing fires the first control, but deleting that control then fails on the second - the registry did not grow across the sizes, so the slope is unmeasured - and a REGISTRY edited to equal sizes passes the first control honestly because each such fixture is truthful about itself. lane_views is deleted rather than left with a dead keep parameter, since lanes was its only remaining caller and that verb's question genuinely is the whole registry, so it keeps the full sweep deliberately. The comment above the call said this was a cheap side-effect-free registry read with no format-gated cost to avoid, which was half true and wholly misleading: side-effect-free it was, cheap it was not, and heads.rs has recorded the same sweep at 4.2 seconds for some time. The replacement quotes the old sentence and refutes it, and the cost argument is hung on Workspace::lane_statuses itself rather than on this one call site, because that is the symbol the next caller with this defect will reach for. find_lane and ensure_lane_name_free do filter after list_lane_entries and are left alone: that is a registry-only read with no graph load and no tree walk - it is what the old comment described, just not what it sat beside - and both are whole-set questions anyway. The land's gate reads flat here and is structurally incapable of anything else, since loot-perf links loot-core and never loot-cli, WORK_COUNTERS is ObjectGets and ObjectDiskReads only, and the_excluded_counters_are_zero_on_this_tier pins TreeWalks at a structural zero - so the pin lives in loot-cli's own tests and a second gate reading would have been theatre against an unchanged binary (#1705) 49b0799a · dbf3dbe6…
• loot ferry parses both policy files once per commit instead of once per changed path, and the instrument had to be built before the fix because PolicyLoads sat on Attributes::load while both ferry doors call parse, so the counter read a structural zero over this whole path and would have read zero after the fix too - a 0-valued counter being indistinguishable from one watching code that does not run. The tally moves to Attributes::parse and Ignore::parse_recorded rather than being routed through a counted door, because the fix itself removes those door calls: a counter on them would read zero afterwards, which is the same blindness relocated. That changes what the counter MEANS, from policy file reads to policy re-derivations, so all three existing pins were re-read rather than adjusted until green - status moves 2/3 to 3/4 with the +1 being its single Ignore::load now counted, and the point is that the GROWTH half passed untouched (narrow equals wide) while only the constant moved, so the test is re-pinned and not re-decided; the tier-exclusion test is still green because the in-process tier links loot-core and never loot-cli, so ADR 0073's exclusion needs no re-taking; and lane_new_sweep's note that policy_loads is one per read_tree_at is repointed to two, since read_tree_at calls both loads. The instrument was proved non-vacuous against the UNFIXED code first, at 18, 66 and 258 parses over four commits of two, eight and thirty-two changed paths, which is exactly 2 plus 2 times commits times width; after, it is 2 plus 2 times commits, so 258 falls to 10 at width 32 and stays 10 as width grows. The most useful thing learned here is a red proof that inverts an assumption: blinding the instrument by putting the tally back on load makes the counter read a constant 1 everywhere, so the constancy pin passes AND the parses-greater-than-zero guard passes, and only the GROWTH assertion catches it - a positive-value pin does not protect against a blinded instrument, which is what ADR 0072's controls bullet credited it with, and that bullet is corrected rather than left standing. This ticket's own wall clock does not reproduce and is corrected rather than repeated: the removed re-parse is 4.63 microseconds per path in release against this repo's real policy files, not 22.0, so a full-history ferry is about 1.9 seconds rather than 8,819 milliseconds - 22.0 is close to the debug reading of 31.53, so the hunt appears to have measured a debug build, and a figure taken under a different build is not a smaller version of the same number. ignored_under is deleted rather than kept as a pure forward once the parse is hoisted, and ADR 0028 is amended because it argued its delete-arm decision partly on an Ignore::parse per deleted path, a cost that no longer exists - the decision stands on the attribution argument, which was load-bearing anyway. seal_under takes a parsed Attributes and narrows pub to pub(crate) since Attributes is crate-private, and its doc said it keeps the bridge from re-parsing the policy twice per path, which was true about the wrong unit: it halved a cost that should never have been per-path. One honest regression is recorded rather than hidden: a deletions-only commit now costs 2 parses where it cost 0, because the hoist is unconditional (#1704) 1822132f · dbf3dbe6…diff
• the policy counter is renamed PolicyParses and policy_parses because it has counted parses since #1704, and the policy.rs block and the ADR 0073 row now point at the variant doc instead of restating why; no stored perf record carried the old key, because the gate does not record this counter. PUSH_SHAPE_DEPTH, OFFER_GUARD_DEPTH and MISSING_DEPTH are literals rather than aliases because their reasons have diverged, and each is still 128. ride_entry takes one RideState instead of three maps, while the one_pass_bundle oracle keeps its own transcribed walk and memo so the byte-identity test still compares two walks, and still went red when the key arm was disabled. the gated counters read 743, 200 and 24 before and after (#1718) bbd04ef4 · dbf3dbe6…diff
• the zero-arity pin now asks owes_an_arity which verbs owe an arity instead of spelling its own narrower rule, and expects the same verbs as before; it went red when owes_an_arity alone exempted heads and when the heads row was re-opened. the OPEN_BUT_TAKES_NONE doc and CONTEXT.md stop listing or counting its readers and point at owes_an_arity. the Admitted doc and CONTEXT.md name the methods that do not read through the spec, as a reading of the impl rather than a rule, and with_leading_word now says it rewrites argv by position. the flags.rs censuses take the src half of the source_walk walk instead of a copy, and the Admitted census still went red on a planted leading_word read in verbs/change.rs; the consumer count is unchanged, and the stale main.rs consumer count in the consumer walk doc is gone. the loot-perf depth docs stop promising an equality nothing checks, change.rs points at the PolicyParses variant doc, and the rewrap leftovers the ticket lists are fixed, with a long line in the CONTEXT.md arity paragraph (#1944) c5819020 · dbf3dbe6…diff

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.