feat(invoice-escrow): enforce escrow duration constraints

[supremeproton01]

Description

The invoice escrow contract now enforces a minimum and maximum duration window when creating an escrow

Closes #83

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📝 Documentation update
• 🎨 UI/UX improvement
• ♻️ Code refactoring
• ✅ Test addition or update
• 🔧 Configuration change

Checklist

• My code follows the code style of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Testing

How to Test

1. Step one
2. Step two
3. Step three

Test Coverage

• Unit tests added/updated
• Integration tests added/updated
• E2E tests added/updated (if applicable)
• Manual testing completed

Screenshots (if applicable)

Additional Notes

For Reviewers

• Code quality and readability
• Test coverage
• Security implications
• Performance impact
• Breaking changes

[drips-wave]

@supremeproton01 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[chizzy192]

Hi @supremeproton01, please rebase/sync your branch with the latest dev branch to resolve merge conflicts and ensure all GitHub Actions CI checks pass cleanly.

[chizzy192]

Hi @supremeproton01, please rebase against dev to resolve conflicts in contracts/invoice-escrow/src/{lib.rs, types.rs}. Ensure your duration constraint validation in create_escrow does not cause arithmetic overflow under 64-bit ledger timestamps, and verify both cargo test --all and cargo build --target wasm32-unknown-unknown --release compile cleanly.