apply dropped the visibility column, and add did too

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

.loom/event-log.md

@@ -1141,3 +1141,47 @@ adoption, which is ours.**
 **Belief that could be shown wrong:** *that an extra round trip on a failure is
 free.* **It is one partial clone on a path nobody takes twice**, *and if adoption
 against large repositories becomes common the listing should be bounded.*
+
+## 2026-09-10 — `apply` dropped the visibility column, reported from use
+
+**Reported by an agent working in another repository**, *who restored the value by
+hand and said the right thing about it:* **losing it silently on every update is
+the kind of thing that only shows up when it matters.**
+
+**Reproduced before diagnosing, and the report was right and understated. Two
+staging sites dropped it, not one:**
+
+```
+before:  4 fields, vis=not-public
+after:   3 fields, vis=
+```
+
+*A staged polad carried `path`, `url` and `etag`, and `apply` wrote the staged
+record verbatim.* **One of the two sites was in `add`, where the value was already
+computed and sitting in a variable three lines above.**
+
+**Fixed in two ways, because they 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* — **inheriting the old value would have
+recorded a fact about bytes nobody holds any more.**
+
+**And `apply` never lets an absent value overwrite a known one.** *A polad staged
+by an older build carries no visibility, and the reporter's tree is exactly that
+state.* **Pinned by a regression test.**
+
+> **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, is worse than not having
+> it* — **it reads as verified and is blank.**
+
+**Belief that could be shown wrong:** *that re-evaluating on apply is worth one
+request.* **It costs a probe per changed document**, *only on the path where
+something actually moved* — **and if reconciliation ever becomes bulk, that is the
+first thing to batch.**
+
+*Found in use, in a repository nobody here was looking at, by somebody who then
+had to repair a lock by hand. **No test we wrote would have caught it**: both
+sites round-tripped fine in isolation, and the field only vanishes across the
+handoff between two of them.*