fix: handle announcement replacement when original is still in purgatory

Previously, has_active_announcement() only queried the database, so when
a newer announcement arrived for the same (pubkey, identifier) while the
original was still in purgatory, it was incorrectly routed as a brand-new
announcement (AcceptPurgatory) rather than replacing the existing entry.

This change splits the logic into two cases:
- If the existing entry is in the database: return Accept (replacement) as before
- If the existing entry is only in purgatory: replace the purgatory entry via
  add_announcement() (which overwrites by key) and extend expiries for both the
  announcement and any waiting state events, then return Accept
- If the owner sends a Reject-classified announcement (service removed) but has
  a purgatory entry: clear the purgatory entry, delete the bare repo, and remove
  any waiting state events before rejecting

Also add an explicit comment to find_accepted_repository() in related.rs
clarifying that it intentionally only checks the database. Related events
should only be accepted after the repository announcement has been promoted
(validated via git data) - this is correct behaviour, not a missing check.

0 files changed, 0 insertions, 0 deletions