Add beneficiary rotation entrypoint to change `sme_address` before settlement

[mikewheeleer]

Description

InvoiceEscrow.sme_address is fixed at init and is the sole authority for withdraw, settle, and record_sme_collateral_commitment, yet docs/ESCROW_BENEFICIARY_ROTATION.md describes a rotation flow that has no on-chain entrypoint. Add a governed rotate_beneficiary so the SME beneficiary can be updated (e.g. for assignment/factoring) without redeploying.

Requirements and context

• Scoped to the LiquiFact escrow Soroban contract.
• Require dual consent: current sme_address auth and admin auth; only allowed in non-terminal states (status 0 or 1).
• Reject rotation to the same address; emit a BeneficiaryRotated #[contractevent].
• Invariant: after rotation, only the new SME may withdraw/settle; collateral metadata ownership transfers with it.
• Align behavior with docs/ESCROW_BENEFICIARY_ROTATION.md.
• Must be secure, tested, and documented.

Suggested execution

• Fork the repo and create a branch:
  • git checkout -b feature/rotate-beneficiary
• Implement changes:
  • escrow/src/lib.rs
  • Tests: escrow/src/tests/admin.rs
  • Docs: docs/ESCROW_BENEFICIARY_ROTATION.md
  • Include rustdoc/NatSpec-style doc comments on public functions
  • Validate security assumptions (auth, overflow, storage TTL, double-spend)

Test and commit

• Run tests: cargo test
• Cover edge cases (zero amounts, overflow, unauthorized callers, double-spend, state-machine misuse)
• Include test output and security notes in the PR

Example commit message

feat(escrow): governed beneficiary rotation entrypoint

Guidelines

• Minimum 95% test coverage on new/changed code
• Clear documentation
• Timeframe: 96 hours from assignment

[Glam26]

@Glam26 has applied to work on this issue as part of the Stellar Wave Program's 5th wave.

Hi, I’d like to work on this issue. I have experience building and auditing smart contract authorization flows, especially around state transitions, secure role rotation, and event-driven architecture in Rust/Soroban environments. I can implement a secure governed rotate_beneficiary entrypoint with dual-consent validation, proper state restrictions, event emission, and comprehensive edge-case testing. I’ll also ensure the documentation and security assumptions align with the existing rotation design while preserving escrow invariants and preventing unauthorized settlement or withdrawal behavior.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Glam26 to this issue.

[drips-wave]

Congratulations, @Glam26! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 2, 2026.

🧑‍💻 @Glam26: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊