Census approval: wake-latency-4

Ruling census-ruling-wake-latency-4. Every change below keeps the disposition it already has, so it needs an approval, not a decision.

Envelopes re-pinned: internal/instancectl, internal/release.

Seal: 86570d1326baad6d866b4066b6bf65218434b201fb1f2c05ebc6e3c79f9c5a98 → 86570d1326baad6d866b4066b6bf65218434b201fb1f2c05ebc6e3c79f9c5a98.

Overlay: internal/provision/testdata/plan14-root-reads-wake-latency-4.tsv, appended to internal/provision/testdata/plan14-root-reads-chain.tsv.

The decision: two new units, written by hand

internal/release/digestcache.go adds two units that read files, so census-propose leaves them to a decision. Their rows are in internal/provision/testdata/plan14-root-reads-wake-latency-4-new.tsv, chained before the overlay above. The seal does not move.

| unit | reads | proposed disposition | |---|---|---| | FileSHA256Cached | file:Open: opens the staged build VerifyStaged names, as FileSHA256 does | authority, B3,J4, root-input;kept=B3;scope=protected-decision-only, the same as FileSHA256 | | SHA256Cached | file:Stat ×2: fstats that descriptor before and after hashing it | the same |

Only the agent calls these, through release.VerifyStaged, which is its duplicate of root's check on the nested path. Root instance control's staged-exe check is unchanged: it hashes in full before every bind into a tenant's namespace. That was Paul's ruling on 2026-10-25, after Astra's finding that a write through an already-writable mapping changes the bytes without moving a timestamp. The agent reuses a digest for an unchanged file identity (device, inode, size, mtime, ctime). A file changed in the last two seconds, or while it was being hashed, is never cached.