[CRITICAL][IDEMPOTENCY] Preserve operation replay protection for the full financial retention window

[Obiajulu-gif]

Summary

Funding, repayment, and refund receipts use a fixed persistent-entry TTL. After a receipt expires, replaying the original external reference can execute the financial operation again.

Repository evidence

• contracts/chainmove-pool/src/lib.rs stores DataKey::Reference receipts and extends them only to the shared fixed TTL.
• Replay detection depends entirely on that receipt being present.

Scope

• Define a financial replay-retention policy tied to pool/position lifecycle and off-chain archival guarantees.
• Keep references alive or anchor compact replay markers for the required period.
• Add an operator-visible path for impending expiry and restoration.

Acceptance criteria

• A replay remains rejected throughout the documented financial retention window.
• Retention is bounded and costed, with restoration behavior defined before eviction.
• Legitimate retries continue returning the original result.

Tests

• Ledger-advance tests through current TTL boundaries.
• Archive/restore and late-replay integration tests.

Non-goals

• General Soroban rent sweeping outside operation receipts.

[muokwejosh-cloud]

I would like to work on this issue, pls assign me.

[grantfox-oss]

🦊 GrantFox — @muokwejosh-cloud has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #171)
2. Your PR will be reviewed by the Chainmove maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@muokwejosh-cloud's PR #205 was approved and merged by @Obiajulu-gif.

🏆 @muokwejosh-cloud: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (697 total points). Track your full progress on GrantFox.

👏 Great work, @muokwejosh-cloud! Keep contributing to Chainmove.