feat(invoice-escrow): implement dispute resolution timeout & default …

[sadiqolalere41-pro]

…fallback

• Add DisputeData type with raiser, reason, raised_at, resolved fields
• Add EscrowStatus::Disputed variant
• Add dispute_timeout_secs to Config (0 = use default 7 days / 604800s)
• Implement raise_dispute: admin-only, Funded→Disputed transition with event
• Implement resolve_dispute:
  • Admin path (within timeout): favour='seller' releases purchase_price to seller (Settled), favour='buyer' refunds funder (Refunded)
  • Default fallback (timeout elapsed): anyone may call; always refunds buyer
  • Both paths unlock invoice token transfers and emit dispute_resolved event
• Implement set_dispute_timeout: admin-only timeout override (0 = reset default)
• Add get_dispute_data view
• Add error variants: AlreadyDisputed, NotDisputed, DisputeNotExpired, DisputeAlreadyResolved, InvalidDisputeFavour
• Add dispute_raised and dispute_resolved event publishers
• Add DisputeData to storage layer
• Fix record_payment distributor path: send amount + investor_amount + platform_fee to distributor so it can pay seller, investor, and admin correctly
• Fix payment-distributor tests: update create_escrow (9-arg) and fund_escrow (3-arg) calls to match updated invoice-escrow API
• Add 19 unit tests covering raise/resolve happy paths, error paths, timeout fallback, event emission, and auth enforcement

Closes #77

Description

Closes #

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

Additional Notes

For Reviewers

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

[drips-wave]

@sadiqolalere41-pro 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 @sadiqolalere41-pro, please rebase your branch on dev to clear line conflicts in contracts/invoice-escrow/src/lib.rs regarding dispute timeout state transitions.