fix(dsl): handle invalid RelLockTime without panicking

[AmosOO7]

Summary

This PR fixes a panic that occurred when the descriptor! DSL macro was invoked with an out-of-range relative locktime value. Prior to this change, older(<value>) used .expect("valid RelLockTime") on RelLockTime::from_consensus(), which panicked if the supplied value did not fit within the consensus limit. The new implementation returns a proper error instead, bringing the macro in line with usual Result-based
error handling elsewhere in the library.

Changes

• Updated dsl.rs older rule to match on the result of RelLockTime::from_consensus() and propagate errors.
• Added comprehensive tests in tests/test_rellocktime_issue.rs:
  • valid common and boundary values
  • invalid values now return an error, not panic
  • demonstration of proper error handling
• Updated documentation/comments and improved test coverage.

No public API changes were made; the fix affects only the macro and error enum.

Testing

All existing tests (cargo test) continue to pass. Added a new descriptor_macro.rs test file exercising the DSL macro directly, and ran full descriptor and wallet test suites to ensure there are no
regressions. All tests currently succeed.

Review Notes

• RelLockTimeError already provides a helpful Display implementation courtesy of the miniscript crate; the error variant simply wraps it.
• The fix is small and isolated; it should be straightforward to backport to earlier releases if needed.

Checklist

• I've signed all my commits
• I followed the contribution guidelines
• I ran just p before pushing

Bugfixes:

• I've added tests to reproduce the issue which are now passing
• I'm linking the issue being fixed by this PR

Related issue

Closes #403

---

Thanks for the review! This is a small but important stability fix that prevents unexpected panics when using the DSL macros programmatically.

[luisschwab]

@AmosOO7 you need to squash these two commits

[AmosOO7]

Done, thanks @luisschwab

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.91%. Comparing base (fca6523) to head (e101b9e).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #404      +/-   ##
==========================================
+ Coverage   79.77%   79.91%   +0.14%     
==========================================
  Files          24       24              
  Lines        5266     5283      +17     
  Branches      241      241              
==========================================
+ Hits         4201     4222      +21     
+ Misses        988      984       -4     
  Partials       77       77              

Flag	Coverage Δ
rust	79.91% <100.00%> (+0.14%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ValuedMammal]

Thank you @AmosOO7. As a follow-up you could consider fixing the .expect for AbsLockTime::from_consensus in the dsl module, or I can open a new issue to track it.

[AmosOO7]

Thank you @AmosOO7. As a follow-up you could consider fixing the .expect for AbsLockTime::from_consensus in the dsl module, or I can open a new issue to track it.

Hello @ValuedMammal, thank you for the review, I will also take a look at the .expect for AbsLockTime::from_consensus in the dsl module, and I will make all the required changes on this PR

[ValuedMammal]

ACK e101b9e