Reported from use in another repository, reproduced before diagnosing, and the
report was right and understated: two staging sites built a lock record without
visibility, not one, and one of them was in add where the value was already
computed three lines above.
Fixed twice over, because the two fixes answer different questions. A staged copy
is new bytes, so its visibility is evaluated afresh rather than inherited — a
source that has gone private since adoption is a new exposure created at the moment
of applying, and inheriting the old value would record a fact about bytes nobody
holds any more. And apply now never lets an absent value overwrite a known one,
which covers polads staged by an older build, the state the reporter is in.
Pinned by a regression test. No test we had would have caught it: both sites
round-trip correctly in isolation, and the field only vanishes across the handoff
between them.
The lock header says visibility is recorded because access is checked once and the
copy is durable. A field that documents its own reason for existing, and is then
dropped by the one operation that updates it, reads as verified and is blank.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018UTxuSizozEA8yDitPuris
