Changes touching this path

• the blob-date window starts at a second the store clock has reached too, so a deposit at a second boundary stops reading as a neighbour date, and the assertion stops naming a cause it cannot tell apart. the rule brackets each of its three deposits with SystemTime::now either side, while a first deposit of new bytes is stamped by the clock behind the file mtime, which trails that one: land inside the trail and the blob is dated one second BELOW a window one second wide, printing the number the neighbour deposit would print, which is why Test - landed main went red at two commits of the 2026-09-16 run with every recorded pair collapsed to before == after. reached deliberately first, as the ticket asked, rather than fixing an unreproduced cause: with a_distinct_second spun to the boundary instead of polled at 20ms, the rule goes red on this windows desktop in the exact CI shape, 9 of 10 runs on the first pass and 10 of 10 on the paired one (0 passed, 1 failed, at position 1 and at position 4), and under that identical amplifier with the fix in it is 10 of 10 green. the fix is NOT a tolerance, which the ticket forbids and is right to: the deposits are a second apart, so a one-second slop would admit the neighbour and delete the property the rule exists for. the window start is a clock read blocked until it is 50ms into its second, so a trailing clock cannot still be in the one before, and that covers the strictly-increasing arm of the same rule and the one-sided arm of a_repeat_deposit_moves_the_anchor_forward, whose soundness rested on the refresh path happening to stamp from SystemTime::now. the granularity is recorded rather than left to be re-derived: a throwaway probe outside the tree stamped a boundary write in the previous second in 232 of 300 rounds, worst trail 1014us, and no mtime came out ahead of the read after the write, which is why only the lower end takes the margin; restore.rs already records 15.6ms for the clock behind a windows file stamp, the reason for the difference was NOT determined, and the margin is set past the coarser of the two. linux is not measured here and the doc says so, since that is the platform CI failed on. the reap rules that compare an idle number carry SLOP 5, which a one-second trail is already inside, and the bucket arm cannot undershoot at all because the fake stamps from this process own clock. with the fix undone and no amplifier the rule is 10 of 10 GREEN here, which is how 51 lands went by. no migration, and nothing outside a shared test module moves, so this owes no deploy. the workspace suite is green over three consecutive runs (3863 passed over 120 binaries, 7 ignored) (#2038) a4942de6 · 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.