Changes touching this path

• the site read tiers read the tree at one version by its manifest key instead of scanning every tree entry on the forge: listTree joined the tree view to the change view, both security_barrier views that Postgres does not flatten, so the join could not reach the tree_entry primary key and was answered with a scan of the whole table, every repo and every version, hashed down to one manifest. tree.ts treeAt now reads the tree view in a lateral subquery keyed by the change row manifest id with OFFSET 0, the #2346 shape, for the anonymous, owner and member tiers alike, and a new entryAt reads one path by (manifest_id, path), which the private blob route and the anonymous blob and diff loaders now ask instead of listing the whole tree and searching it. the views and their gates are unchanged and no migration is needed. measured as forge_owner on a throwaway Postgres 18 with 1,400 changes and a 7,240-path head, median of 7 runs (of 5 on one core): at 1.5M tree_entry rows the listing went from 148.7 ms (304.5 ms on one core) to 19.1 ms, at 7.6M from 607.9 ms (1,618 ms on one core) to 18.6 ms, and the one-path read is 0.26 and 0.25 ms where the blob route paid the whole listing, the same 7,240 rows and md5 before and after. pinned: a plan pin in owner.pg, member.pg and read.pg asks for both statements with nested loops and sequential scans priced out and refuses a tree_entry read not keyed by the change row manifest id, beside one-path tests on each tier. red under named mutations, each restored, over the 7 selected tests: the old join (3 failed and 4 passed), OFFSET 0 dropped (3 and 4), the old join for the one-path read alone (3 and 4), and the path filter dropped (3 and 4). bands() in the history route has the same scan (about 860 ms at 7.6M rows) and is left as it was, with a comment saying why the lateral alone does not cure it there. cargo test green, 4757 passed over 144 binaries with 13 ignored, the site live suites at 85 passed and the site gate at 863 passed. owes a site deploy (nyvxmxqz) 7e0ae25b · 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.