A forced resync always minted a fresh rkey, writing a second
sh.tangled.repo record and leaving the first pointing at a dead
repoDid. Seen in production: two records for one repo, 95 minutes apart,
different repoDids. Now reuses the existing record's rkey via the lookup
syncRepoMetadata() already had, extracted as findRepoRecordByRepoDid()
and shared by both callers with syncRepoMetadata() behavior unchanged.
Confined to tangled-repo.ts and its unit tests. The old knot-side repo
is still orphaned -- that needs the "poke the knot to re-sync from source"
verb the existing comment calls a future improvement, so that caveat
stays.
Untested against a live knot: the reused rkey now also goes to
repo.create, and if knot1 rejects a repeated rkey,
isNameConflictResponse() would read the 400 as a name conflict and mark
the repo terminally errored. The alternative -- fresh rkey to the knot,
existing rkey for the PDS record -- avoids that but desynchronizes the two
identifiers.
Tests: full unit suite passes. Adds two cases to tangled-repo.spec.ts:
a forced re-enroll reuses the existing record's rkey and preserves
unmanaged fields, and falls back to a fresh rkey when no record matches.