Fix: the approved column silently unapproved every pre-existing peer
The migration adding dynamic_repo.approved defaulted every row to 0,
including rows that were already materialized (live) under the old
model — federation-x-f3 among them. AllDynamicRepos now filters on
approved=1, so on the very next restart after this deploy, f3 silently
dropped out of live.syncers entirely: no error, no log line, just gone.
Caught live: its README stayed stuck for ~35 minutes across a restart
while f1/f2/bimr kept moving, and it sat invisible in /admin/pending
(a peer that had been live for hours suddenly asking to be
"re-approved" is exactly the tell).
Fixed with a startup backfill — UPDATE dynamic_repo SET approved = 1
WHERE materialized = 1 AND approved = 0 — idempotent (materialized
never reverts to 0), so safe to run unconditionally every startup, not
gated on "is this the first run after the column was added." Verified
with a test that closes and reopens a store with a pre-existing
materialized row and confirms it survives migration approved; verified
live: f3 reloaded on restart, dropped out of the pending queue, and
resumed picking up new commits.
Also: dropped the Radicle-side sentence from /add-peer's lead
paragraph (redundant with the field-level hint already there).