Changes touching this path

• the lane runbooks stop assuming a shell that remembers anything (#883) Found running ticket-to-lane for #867 end to end. Its step 4 exported LOOT_SESSION in bash and its step 5 said to cd into the lane, all subsequent work happening there — and neither survives a call here. Variables do not carry, and this repo resets the working directory back to the primary after every call, so step 5 certified a state the harness discarded a moment later and every one of the ~20 later commands needed its own Set-Location. The reset is a good default, so the runbooks lean into it rather than fight it: a lane is a path you carry, not a directory you move into. Step 5 becomes Pin the lane path. The rule is shared — land-change runs entirely from a lane — so it lands once in BINARIES.md beside Where you run them, as the fresh shell, with both skills pointing at it. It names the two things that ride every call and not just the first: the Set-Location prefix, and $env:LOOT_SESSION, which was written as a spawn-time formality even though lane gc is session-scoped too and needs the same label set again in that call. Three smaller ones from the same run: step 1 gains a `git log origin/main --grep=(#<n>)` check, because open is not unbuilt here and a ticket whose work landed under another id stays open until someone notices; the BINARIES pointer said before step 1 when the first loot call is step 3; and the primary-only rule was stated three times, so the guardrail bullet folds into step 4, where its mechanism explains why step 3 checks at all. The frontmatter description promised the skill cds you into the lane, which the step 5 change makes untrue — it now says it hands back the path. 3bf849b5 · 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.