Add regression test for cancel_settlement/execute_settlement/cancel_expired_settlement all targeting an already-Executed settlement

[Jagadeeshftw]

📌 Description

Each of execute_settlement, cancel_settlement, and cancel_expired_settlement independently checks settlement.status != SettlementStatus::Pending and returns Error::InvalidSettlementState, but there is no single regression test exercising all three against the same already-Executed settlement id to confirm none of them can be tricked into double-releasing or double-crediting liquidity for a settlement that has already been finalized.

🧩 Requirements and context

• Add a regression test that opens and executes a settlement, then calls execute_settlement, cancel_settlement, and cancel_expired_settlement (with expiry configured and elapsed) against the same id in sequence.
• Assert all three calls fail with Error::InvalidSettlementState and that neither Pool.total nor fees_accrued change as a result of any of the three failed calls.
• Repeat the same three-way check against an already-Cancelled and an already-Expired settlement for full lifecycle coverage.

🛠️ Suggested execution

• Add the test to src/test.rs, snapshotting pool/fees_accrued before the three post-finalization calls and reasserting after each.
• Reuse existing settlement-lifecycle test setup helpers.
• No production code changes expected given each function already independently guards on status; this closes a cross-function, same-id regression gap.

✅ Acceptance criteria

• A regression test confirms all three terminal-state-sensitive functions reject action against an already-Executed settlement.
• The same check is repeated for already-Cancelled and already-Expired settlements.
• No pool or fee state changes result from any of the rejected calls.

🔒 Security notes

A double-release bug here (e.g. cancelling an already-executed settlement and crediting the pool a second time for liquidity that was already released to the anchor) would directly inflate a pool's reported liquidity beyond what was ever actually deposited — a serious fund-accounting integrity issue.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours