Changes touching this path

• the gate proves the tree the position holds, and main receives the merge: a land refuses a lane behind landed main (#939) main went red at 3597c9d with two lands that each passed their own gate: #920 added a caller (`Ignore::parse`) in one file, #921 deleted the callee in another. Disjoint edits, no path in common, so loot per-path conflict detection had nothing to look at — and each land compiled the tree its LANE held while the ferry projected the MERGE, a tree nothing had ever compiled. The repair is one line: #920 test takes `parse_recorded`, the sole parse since #921, which is also what it means (it pins the shipped file behaviour, not a live-tree strictness that no longer exists). The guard is the rest. `Workspace::behind_landed_main` is the read-only half of the `covered` question `adopt` already asks, and `land_gate` refuses on it, naming what it is behind and pointing at `loot adopt` + a re-review. The land does not adopt for you: a catch-up merges, a merge can conflict, and burying that inside the verb whose promise is shipping the reviewed change is the wrong place for it. The same question is asked again after the gate and before the finalize, for the sibling land that completes inside a multi-minute cargo test — there rather than inside the harbor lock, which would be airtight and would serialize every concurrent land behind one full test suite (the ADR 0036 cost). The residual window is the git-quiet finalize plus the lock acquisition; workflow.md names it rather than papering over it. 510a5be7 · 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.