Changes touching this path

• the three sites that acted on a tree entry unsigned visibility ask the seal now, and the bundle key lane stops reading that field at all: #1892 censused who reads a change tree entry visibility, refused a blanket ingest check at apply_sync, and left these three deciding on a value that sits outside the content address, outside the change id and outside the finalize signature, so on a tree that came from a peer it is a claim under no signature. ride_entry read open off the manifest entry while reading anyone off the object a line above, so an entry recording Internal over an embargoed seal put that content key into a sync bundle any peer can hold; it reads the seal the same probe already returned, memoised per address beside anyone, and costs no store read the walk was not already paying. the same predicate on the batched path moves with it, since a transfer with a second batch would otherwise reach the old answer: the key rule comes out of wanted_finalized_entries, which answers presence alone now, and bundle_objects_only asks the object it is already holding. embargoed_paths takes the reveal_at a timed relay grant is withheld until from embargo_reveal_at, the door #1578 built for that number at loot grant --relay, and the entry number survives only where the seal cannot be produced, which is a state where grant_sealed cannot produce a deposit either. publish_gate asks seal_visibility beside the oid_is_published read it already makes of the same object, and refuses where the seal cannot be read rather than swallowing, because a swallowed published-ness read asks for consent already given while a swallowed embargo publishes content nothing could say was unsealed. each pin carries both directions, since a repair that only tightens is as wrong as one that only loosens, and none of them compares the two recordings, which ADR 0012 records as supposed to differ once put_vis_redacted has stripped a holder list on the wire. the rows for the sites that stopped binding the field left #1892 census rather than changing class, a discard being no row by its own definition. red under mutation, counts read each time: ride_entry open restored to the manifest entry (negotiation 34 passed and 3 failed, the byte-identity difference red beside both direction pins, and the census 2 passed and 1 failed naming bundle_impl_within@1#1 and @1#2), the batched key arm stopped from asking (35 passed and 2 failed, naming the follow-up batch arm), the deposit reveal time taken off the entry again (custody 65 passed and 1 failed, reading Some(0) where Some(9000) belongs), the publish gate embargo read taken off the anchor entry again (loot-cli 0 passed and 2 failed, red in both directions, and the census 2 passed and 1 failed naming publish_gate@1#1) and the unreadable seal swallowed (2 passed and 1 failed, naming ghost.txt). no migration and no wire or format byte moves, but the key lane decision moves on the client bundle builder and on the relay fetch path, so this rides the next release and owes a relay deploy. the workspace suite is green (4101 passed over 132 binaries, 8 ignored) (#2185) 0a33e5c4 · 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.