Changes touching this path

• verbs/: seam scaffold + the repo family (init/clone/config) (#661) 28849eaa · dbf3dbe6…
• verbs/lane: the lane family (new/list/merge/name/rm/gc, lanes) (#661) b4504930 · dbf3dbe6…diff
• a lane carries its own hold, and custody crosses back whole at finalize (#811) 941cafb9 · dbf3dbe6…diff
• a ticket claims one lane: a repeat claim refuses instead of forking a silent sibling, and one search answers for both the id and the directory (#1002) dda6e6a6 · dbf3dbe6…diff
• the primary stops authoring: describe -m and new -m refuse on a shared floor and print the exact lane take that carries the work onward - ADR 0058's loot lane take built, --allow-primary now a triple (#985) 67df9345 · dbf3dbe6…diff
• a lane path prints as something you can paste: the \\?\ extended-length prefix comes off at every face, machine ones included, while the registry keeps the canonical form (#1049) 181fd4f6 · dbf3dbe6…diff
• the one-place path spellings become reachable and reach: tree_path goes pub(crate) and covers the five walk-derived surfaces that could not call it, lane merge stops being the face #1049 missed, and two doc claims shrink to what is true (#1063) 94908511 · dbf3dbe6…diff
• a verb that could only publish to main unreviewed is retired: lane merge goes, its fold machinery stays where adopt needs it, and the mirror-free fold that genuinely leaves with it is named rather than glossed (#1048) 3f7635a9 · dbf3dbe6…diff
• 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…diff
• lane gc and lane rm name what holds a lane they cannot reap and give a way back for a lane that lost its lane-id. on Windows a held path that is a directory is now reported as held by a file open inside it or by a process whose current directory is inside it, which holds the directory with no file open, a held file is told a process has it open, and both say loot cannot name the holder, point at Resource Monitor, and say to leave the lane alone and re-run; POSIX, where a current directory does not block removal, is told the path is busy. the refusal for a directory without a matching lane-id now names loot lane rm <id> --deregister, a new flag on rm that drops the registry entry and leaves the directory untouched, keeps the ownership guard, and refuses while the directory still carries the matching lane-id, because there the entry is what lets a retried reap finish, which also answers the ticket question about deregistering a held landed lane: no. a new test spawns a real sleeper process whose current directory is a temp lane and went red with the old advice and with the sleeper removed; its POSIX branch asserts the sweep reaps and was not run here. a deregister test went red with the recovery hint, the still-a-lane refusal or the ownership guard removed and with the directory deleted, and a cli test went red with the flag not passed through. the verb tier width moves to the derived count, and CONTEXT.md and the concurrent and issue-tracker runbooks say to leave a held lane alone and name the recovery. the workspace suite is green (#1760) 16968085 · 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.