Changes touching this path

• the History view reads its ledger and its bands by key: the ledger walk reads each step of parents through a lateral OFFSET 0 subquery over the parent view, and the page change rows and the size count read the change view the same way, so no step reads every change on the forge; bands() restricts the change view by the version ids it was asked for and reads the tree view laterally by manifest id and path, and forge migration 0028 adds change_node_by_manifest, the index the tree view gate asks a change by, so that gate no longer scans change_node once per touched path. the views and their gates are unchanged. measured as forge_owner on a throwaway Postgres 18 with 5,000 changes and 7.6M tree entries, medians of 7: page 1 of the ledger of a 1,400-deep line 1.7 s to 21 ms, its size query 1.7 s to 19 ms, and the bands of a 50-version page whose changes touched 6,356 paths, the ids bound as one array as the site binds them, 25.7 s to 56 ms, and 547 ms without the index. pinned in plan pins in owner.pg, member.pg and read.pg refusing an unkeyed read of change_parent, change_node or tree_entry in the ledger page, the size and the bands, planned with change_node holding enough rows that a keyed read wins, since on a near-empty table the gate read tied with a walk of the primary key and was taken. red under named mutations, each restored, each 3 failed and 7 passed over the 10 selected tests: the step as a plain join, the step without OFFSET 0, the page change rows as a plain join, the size count as a plain join, the bands tree read as a plain join, the bands change read without the id restriction, and the index dropped. not taken: an index on path_touch(repo_id, version_id), since the scan of the repo touches took 2 ms of the 60 ms bands query. cargo test green, 4829 passed over 144 test result lines with 14 ignored, the site gate green at 892 passed, and the site live suites 88 passed, also on a fresh cluster through ci/local.sh. owes a forge deploy for migration 0028 before the site deploy; it also carries the comment of review sweep 5 on mpkswzkl and files its fix-up ticket ztyxspll (rlztuvmo) c8bae938 · 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.