Changes touching this path

• a stale core stops saying grantSealed and starts saying rebuild: the SDK suite stamps what it was built from (#914) sdk/wasm/ is generated by wasm-pack from crates/loot-wasm and ignored by git AND by loot, so it is the one input to the SDK suite that no checkout, land or lane spawn ever updates — and nothing checked it. The failure did not look like staleness: measured during #880, an out-of-date core produced 14 failures inside test/grants.unit.test.ts naming an arity mismatch on grantSealed, which reads as a defect in sealed-grant handling. It cost a diagnosis aimed at the most security-sensitive code in the repo, for a bug that did not exist. So the value is not preventing the stale run, it is making the stale run SAY SO — the same shape as #843 and #847. `build:wasm` now records a stamp of what it built from; `pretest` compares it and refuses, naming the rebuild and the #880 misdiagnosis so the next reader does not repeat it. Content stamp, not mtime: this repo materializes whole trees routinely (every lane spawn, adopt, op restore), so mtime would cry stale on a correct build several times a day, and a guard that fires on a healthy tree gets switched off. The hash covers loot-wasm path-dependency CLOSURE (walked, so a new path dep joins on its own) plus the workspace manifest and lockfile — not all of crates/, which would demand a 30s wasm rebuild every time an unrelated crate moved. Proven in a lane: not-built refuses before vitest, a real wasm-pack build then passes the check, and one appended line in loot-codec is caught. The behaviour suites additionally need target/release binaries in the checkout — README now says so, since a fresh lane fails them with ENOENT until cargo build --release runs. 151884a4 · 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.