[hieblmi]

Limit the static Loop In risk-decision replay cache to 1,024 swap hashes shared by accepted and rejected decisions. Eviction removes all associated cached state; existing-hash updates preserve their slot. Persistence attempts, delivery to active subscribers, and replay within the capacity limit are preserved.

Add receive-loop flood coverage across all persistence modes, plus replay, existing-hash updates, and live delivery at capacity.

Validation:

• go test -race ./notifications ./staticaddr/loopin
• Repository-pinned golangci-lint run --new-from-rev=upstream/master ./notifications (0 issues)

Pull Request Checklist

• Add an entry to docs/release-notes/release-notes-next.md, or apply the no-changelog label (required by CI).

[starius]

The fix is correct.

There is one concrete remaining memory-exhaustion risk: the cache retains complete protobuf messages, including unknown fields (swapserverrpc/server.pb.go:3033). With gRPC’s default 4 MiB message limit, 1,024 padded notifications could retain approximately 4 GiB. This predates the patch, but limits its protection. Caching fresh notifications containing only the validated hash would address it.

Currently we evict a random record. We can drop a fresh decision before its swap subscribes (about a 1-in-1,024 chance per new entry). Evicting the oldest entry first would avoid this, but it's optional.

[hieblmi]

I striped most of the protobuf message and only retain the swap hash of the risk decision.