fix(relay): republish NIP-IA snapshot on idempotent archive retry

[santhiprakash]

Fixes #4617

Problem

When handle_identity_archive_event processes an archive/unarchive request whose target identity is already in the desired state, db.archive / db.unarchive returns changed = false (ON CONFLICT DO NOTHING). The handler returned Ok(()) immediately — before publish_nipia_archival_list ran.

If a prior request successfully wrote archived_identities but the kind:13535 snapshot publish failed transiently, retrying the same archive/unarchive request reports success to the client while the authoritative snapshot is never republished. That failure mode is unrepairable by retry.

This is distinct from #3848 (same-second created_at collision on the snapshot), which is addressed separately in #3954.

Triage / Root cause

In crates/buzz-relay/src/handlers/identity_archive.rs, the early return on !changed skipped both the delta publish and the archival-list snapshot. The snapshot is a pure function of archived_identities, so republishing it on the idempotent path is safe even when no state transition occurred.

Fix

On changed == false, skip publish_nipia_archived / publish_nipia_unarchived (no delta to describe) but still call publish_nipia_archival_list.

Verification

• cargo test -p buzz-relay identity_archive
• cargo clippy -p buzz-relay -- -D warnings

Notes / Risks

• Minimal one-path change; no schema or API surface changes.
• Checked for duplicate PRs referencing NIP-IA: failed kind:13535 snapshot publish is unrepairable — changed=false early return skips publish_nipia_archival_list on every retry #4617 or this handler path — none found.
• fix(relay): force monotonic created_at on NIP-IA archive snapshots (#3848) #3954 addresses the separate timestamp-collision bug in snapshot publishing.