refactor: split InvalidDeadline into precise errors

[AugistineCreates]

This pr closes #509

Description

This PR splits the overloaded use of Error::InvalidDeadline (which was previously returned for both a past end timestamp and structural mismatches) to allow the backend errorHandler.ts to surface precise, unambiguous user-facing validation errors.

Key Changes

1. Mangled Codebase Cleaned Up & Restored
   • Cleaned up the local prepended dummy modules from the top of lib.rs and test.rs which were introduced by a previous bad merge.
   • Cleaned up duplicate dependencies in contracts/accountability_vault/Cargo.toml.
2. Added DeadlineInPast Error Variant
   • Added a new contract error variant: Error::DeadlineInPast = 28.
   • Updated create_vault inside lib.rs to return Error::DeadlineInPast when the configured end_timestamp is less than or equal to the current ledger timestamp.
   • Kept Error::InvalidDeadline strictly for structural mismatch checks (such as a milestone due_date exceeding end_timestamp, non-monotonic due-date ordering, or deadline extensions that do not exceed the current end timestamp).
3. Backend Error Catalog Mapping
   • Updated the backend src/middleware/errorHandler.ts SorobanErrorCatalog to map error code 28 to ErrorCode.VALIDATION_ERROR with a precise Deadline is in the past message.
4. Unit Tests
   • Added two targeted unit tests in contracts/accountability_vault/src/test.rs:
     • test_create_vault_deadline_in_past_fails (asserts Error::DeadlineInPast is thrown).
     • test_create_vault_milestone_due_date_exceeds_end_fails (asserts structural mismatch continues throwing Error::InvalidDeadline).
5. Documentation
   • Documented the split mapping rules in contracts/README.md.

[drips-wave]

@AugistineCreates 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