Changes touching this path

• not a lane is not the same as shared: the finalize notice stops telling clone users their private tree is crowded (#967) The #436 warning fired on `lane_id().is_none()`, which is true of the dev primary AND of every clone (ADR 0026) — and then asserted that other sessions share the tree and pointed at `loot lane new`. In a clone every clause is false: separate repo, own store, own keypair, nobody else in it, and the clone already IS the isolation. Its audience is the reader least able to catch that, because a clone exists for a different AUTHOR (ADR 0047). The position now asks the store how many other positions exist over it (`registered_lane_count`, the registry read without the per-lane peek — a finalize is not the place to pay a `loot lanes` sweep) instead of inferring it from its own name. That is a fact rather than a guess and it is right in both directions the moment it changes. Two texts, because the hazard has two sizes and saying the larger one everywhere costs the smaller one its credibility. With siblings: named, counted, and the lane remedy. Without: the half that is always true — this signed the tree in front of you, `loot undo` steps it back. ⚠ The old #436 test asserted the sharing clause over a freshly init-ed repo with no lanes at all — byte-for-byte the state of a clone — so it was pinning the bug. It now spawns a lane first, to MAKE the claim true rather than assume it, and #967 gets its own test for the negative. Proven by running it: a lane-less repo says `directly on the working tree (no lane)`, and the same repo one `lane new` later says `1 lane live over this store — they share it`. 2f805d57 · 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.