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…

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.