[Quality] Add replay protection to inbound transaction callbacks

[1nonlypiece]

Problem

Repeated callbacks or maliciously replayed payloads can cause duplicate notifications, state transitions, or audit entries.

This issue requires a meaningful production implementation. Typo-only, documentation-only, formatting-only, dependency-only, or cosmetic changes do not satisfy the scope.

Objective

Make callback processing idempotent using authenticated event identity and durable deduplication.

Scope

Define the signature and freshness checks, persist processed event IDs, handle concurrent delivery, and separate rejected events from retriable failures.

Acceptance criteria

• A valid callback delivered twice produces one state change.
• Unsigned, stale, malformed, and incorrectly scoped callbacks are rejected.
• Deduplication records have a bounded retention strategy.
• Tests cover concurrent duplicate delivery and retry behavior.
• Existing CI/CD checks remain green.
• The PR explains the design, tradeoffs, test evidence, and any remaining limitations.
• The PR references this issue with Closes #{issue-number} or Fixes #{issue-number}.

Implementation notes

Implement only the stated behavior; keep unrelated refactors out of the PR.

Non-goals

• Do not remove tests merely to make CI pass.
• Do not introduce secrets, private keys, credentials, or mainnet-only values.
• Do not change unrelated APIs, UI surfaces, contract behavior, or deployment configuration.

Contributor application

Before starting, comment with relevant experience, a 1–4 bullet implementation approach, and an estimate for opening the first draft PR. Wait for maintainer assignment before coding. Only the assigned contributor is eligible for reward consideration.

Submission requirements

• Use PR title format [#<issue-number>] <short summary>.
• Check off each completed acceptance criterion.
• Include focused automated tests for success, failure, authorization, and boundary behavior where applicable.
• Include the validation commands and results in the PR description.
• Address maintainer review feedback before merge.

GrantFox reward consideration is based on the original scope, implementation quality, tests, security review, CI/CD results, review feedback, and follow-up stability; completion or merge alone is not a guarantee.