Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/p2p/src/peer_network_service.rs`:
- Around line 1105-1134: evict_peer_on_network_mismatch currently performs an
independent DB delete (db.update_scoped + delete_peer_list_item) which races
with the periodic flush (persistable_peers_with_mining_addr / flush), allowing
the flushed snapshot to resurrect the peer; change this so eviction is
serialized with the flush writer: do not run a standalone delete in
evict_peer_on_network_mismatch; instead mark/remove the peer in PeerList and
either (a) enqueue the peer_id for removal to the same flush/DB writer (or call
a new PeerList method that acquires the same lock used by flush and performs the
delete inside the flush's DB transaction), or (b) have flush consult a removal
set (updated by evict_peer_on_network_mismatch) and perform
delete_peer_list_item within its transaction; reference
evict_peer_on_network_mismatch, PeerList,
persistable_peers_with_mining_addr/flush, delete_peer_list_item and
db.update_scoped when making the change.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/p2p/src/peer_network_service.rs`:
- Around line 237-261: The code drains pending_db_removals (std::mem::take)
while holding the lock before calling db.update_scoped, which loses staged
removals if the transaction fails; instead, while holding the lock capture a
clone/copy of pending_db_removals (do not std::mem::take) and release the lock,
run update_scoped using that cloned set (removals_clone), then if update_scoped
succeeds reacquire self.state.lock().await and remove those successfully-applied
IDs from pending_db_removals (or clear them) so removals are only dropped on
successful transaction; refer to pending_db_removals, state.lock().await,
update_scoped, and the local removals variable to locate where to change the
logic.

In `@docs/superpowers/specs/2026-06-02-gossip-handshake-enforcement-design.md`:
- Around line 97-103: Update the docs to reflect that on outbound-announce
rejection (the PeerResponse::Rejected arm in announce_yourself_to_address) you
should still evict the peer from the in-memory cache using
remove_peer_by_api_address, but do NOT perform immediate DB deletion; instead
record the peer in pending_db_removals and let the DatabaseProvider-only writer
apply deletes during flush via db.update_scoped, preserving the existing error
return when rejected_response.reason ==
version::RejectionReason::NetworkMismatch.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@crates/p2p/src/peer_network_service.rs`:
- Around line 246-270: The flush() path can race with concurrent NetworkMismatch
evictions because the peer snapshot (persistable_peers) and staged removals
(pending_db_removals / removals) are taken separately; to fix, make the snapshot
and the staging of evictions atomic under the same state mutex so you cannot
re-persist a peer that was evicted after the snapshot: acquire self.state.lock()
around the sequence that calls peer_list.remove_peer_by_api_address(...) /
pending_db_removals.insert(...) and the code that creates persistable_peers and
removals, then release the lock before calling db.update_scoped(...) (leaving
transaction logic unchanged); apply the same locking pattern where peer removals
are staged (the peer_list.remove_peer_by_api_address and
pending_db_removals.insert sites) so the update_scoped(tx ->
insert_peer_list_item / delete_peer_list_item) always operates on a consistent
snapshot.
- Line 1236: The async tests
network_mismatch_rejection_evicts_from_cache_and_returns_id,
non_network_rejection_retains_peer, and
flush_deletes_pending_removals_without_resurrecting (and the other occurrences
around 1327-1328, 1363-1364, 1396-1397) should use the #[tokio::test] attribute
instead of importing tokio::test and annotating with #[test]; update each test
function to replace #[test] with #[tokio::test], remove the standalone use
tokio::test; import (or any unused import) if present, and ensure the async fn
signatures remain unchanged so the tests run under the Tokio runtime.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@crates/p2p/src/peer_network_service.rs`:
- Around line 1120-1138: The code currently emits AnnouncementFinished {
success: true } before handling PeerResponse::Rejected, causing rejected
handshakes to be recorded in successful_announcements; instead, only emit the
success announcement after matching PeerResponse::Accepted and for
PeerResponse::Rejected emit a failure (non-retry) announcement so the
successful_announcements cache is not populated for evicted peers. Concretely,
move the AnnouncementFinished { success: true } emission out of the common
pre-response path and into the PeerResponse::Accepted branch, and in the
PeerResponse::Rejected branch send a failure announcement (with success: false
or a distinct non-retry event) before calling evict_peer_on_network_mismatch and
inserting into state.pending_db_removals; update any handlers that expect the
announcement shape accordingly (references: AnnouncementFinished,
successful_announcements, PeerResponse::Accepted, PeerResponse::Rejected,
evict_peer_on_network_mismatch, pending_db_removals).

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/domain/src/models/peer_list.rs`:
- Around line 1440-1480: Update the test
remove_peer_by_api_address_clears_all_lookups to also verify the gossip lookup
and emitted removal event: after calling
peer_list.remove_peer_by_api_address(&api), assert that
peer_list.peer_by_gossip_address(&peer.address.gossip) (or the appropriate
gossip address field) returns None, and assert that the PeerRemoved event was
emitted (check the event stream/queue or peer_list.recent_events()/last_event()
for a PeerRemoved containing the removed peer_id); reference the
functions/methods peer_by_gossip_address, remove_peer_by_api_address and the
PeerRemoved event type to locate where to add these assertions.

In `@crates/p2p/src/peer_network_service.rs`:
- Around line 1120-1142: The code currently treats any HTTP-level
Ok(peer_response) as an announcement success, which lets NetworkMismatch
rejections remain recorded in successful_announcements; instead, only emit the
AnnouncementFinished { success: true, retry: false } notification from the
PeerResponse::Accepted arm and for PeerResponse::Rejected return/report an
announcement with success: false, retry: false (so handle_handshake_request()
won't cache rejected peers in successful_announcements). Update the
PeerResponse::Rejected branch (where evict_peer_on_network_mismatch(...) and
pending_db_removals.insert(...) are done) to report failure (success:false,
retry:false) and keep returning
PeerListServiceError::PeerHandshakeRejected(rejected_response), and move the
success notification logic into the PeerResponse::Accepted branch; ensure
references to successful_announcements handling and any AnnouncementFinished
emission are adjusted accordingly.