fix(loan_manager): cap how far a single extension can push the due date

[N-thnI]

extend_loan capped how many times a loan could be extended (MAX_EXTENSIONS = 3) but said nothing about how far. extra_ledgers was only checked for non-zero and for u32 overflow, so one call with a huge value pushed due_date past any realistic horizon and deferred default indefinitely — for a flat 1% fee charged once on remaining principal. Total extendable time was unbounded.

A single extension may now be at most the configured term ceiling, rejected with LoanError::InvalidExtension. Total deferral is consequently bounded by MAX_EXTENSIONS * max_term instead of being open-ended.

The bound is derived from configuration, not a constant. New internal helper max_term_ledgers() reads DataKey::MaxTermLedgers, and get_max_term_ledgers() now delegates to it so the ceiling an admin reads back is the same expression as the one enforced, rather than two copies that can drift.

The helper falls back to DEFAULT_TERM_LEDGERS when the key is unset, not to u32::MAX. refinance uses a u32::MAX fallback for the same key; copying that here would have left the new bound inert on any deployment whose admin had not configured term limits — precisely the deployments least likely to notice the abuse. refinance's own fallback is left alone as out of scope.

Also converts the due-date checked_add from .expect() to a typed error. The issue asked for overflow-safe math with no unwrap/panic, and a panic there would revert the transaction after the borrower's extension fee had already transferred, with no diagnosable cause. The new ceiling makes overflow unreachable in practice; the arithmetic stays checked regardless.

Preserved unchanged: the MAX_EXTENSIONS count cap, the non-zero check and its distinct InvalidTerm code, and the 1% fee formula (out of scope).

No lower bound was added. It is listed as optional, and rejecting dust extensions would refuse legitimate short ones while preventing no abuse — a 1-ledger extension costs the borrower a full fee and burns one of three slots, so it only ever harms them.

7 new tests: over-long rejected with no state change, exactly-at-ceiling accepted, u32::MAX and u32::MAX-1 rejected (the latter previously reached checked_add), the ceiling tracking set_max_term_ledgers in both directions, three maximal extensions then the count cap refusing a fourth, and the non-zero check still returning InvalidTerm.

137 tests pass; cargo fmt --check and clippy clean (the one clippy warning is pre-existing in events.rs, untouched here).

Pull Request Checklist

Please ensure your PR follows these steps, mirroring our CONTRIBUTING.md guidelines.

• I have read the CONTRIBUTING.md document.
• My code follows the code style of this project.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have updated the documentation accordingly.
• I have verified the changes locally.

closes #1126