Changes touching this path

• the store grows the inventory: classification as data, an exhaustive save walk, and a View derived from the captured rows (#863) Land B of #863 (decision #851), closing the ticket. One static row per artifact in loot_core::store carries what the getters' doc comments said in prose: ownership class (ADR 0034's three), undo membership (captured at a pinned wire ordinal, or excluded with the reason as data — `lost` stays shared AND excluded, because a view reset must not un-acknowledge accepted loss), and the artifact's place in the walk. The engine's save_to persists the shared surface by one exhaustive dispatch over the table, so adding an artifact without deciding its persist story fails to compile; the op-log View's entries derive from the captured rows in ordinal order, with ordinals below the pinned inline count encoding inside each op and every later ordinal riding its own trailing section — the discipline bisect (#390) and resolved (#744) established by hand, now produced by the ordinals themselves, so old op logs decode unchanged and a new captured row is one inventory row whose existence IS its undo coverage. Structural tests pin the table: dense unique ordinals, capture implies position ownership, and every row's path agrees with its class (keyring/escrow project, ADR 0047). d05a0c46 · 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.