[Quality][High] Make liquidation accrual and closeout arithmetic overflow-safe

[Baskarayelu]

Objective

Centralize checked accrual math and define exact boundary behavior for liquidation, repayment, and closeout.

Why this matters

Accrued value grows across time and rate parameters. Overflow, rounding direction, or stale timestamps can undercharge or overcharge a position.

This is a substantive production-quality improvement. It must change runtime behavior, security guarantees, correctness, reliability, or meaningful user functionality. It is not a documentation-only, formatting-only, or trivial dependency task.

Scope

Area: liquidation and interest math

Starting points: docs/liquidation.md, docs/COMPOUND_RATE.md, credence_bond and math crates

The contributor should verify the current implementation before changing it and keep the PR limited to this issue. Do not introduce unrelated refactors or weaken existing CI/security gates.

Acceptance criteria

• All arithmetic is checked and returns stable contract errors on overflow.
• Accrual uses a single timestamp/rate convention across preview and execution.
• Rounding direction is deterministic and cannot create value.
• Liquidation cannot occur before its eligibility boundary or twice after closeout.

Required validation

• Add property tests for monotonicity and conservation across randomized rates/times.

• Test exact boundary, maximum duration, zero rate, and overflow inputs.

• Add repeated liquidation/repayment regression tests.

• The PR explains the failure mode, the chosen design, backward-compatibility impact, and rollback or migration considerations.

• The PR includes CI evidence and does not contain secrets, generated noise, unrelated cleanup, or disabled checks.

Contributor deliverables

• Open a focused feature branch and do not begin implementation until assigned.
• Reference this issue with Closes #<issue-number> or Fixes #<issue-number>.
• Check off every acceptance criterion in the PR with links to the relevant code and tests.
• Include a security/correctness note explaining why adversarial inputs cannot bypass the new guarantee.

Maintainer quality bar

The PR must be independently reviewable, preserve existing behavior outside this scope, exercise failure paths, and pass the repository's complete required CI/CD checks. Reward eligibility is not guaranteed by this issue or by merging.

[safal207]

I would first pin the current failure with a test where preview and execution receive the same timestamp and rate but diverge through overflow or rounding. The fix should then route both paths through one pure checked-accrual function that returns a stable contract error before any position mutation.

The property suite would compare one long accrual interval with equivalent smaller intervals, exercise randomized rates and durations, and track the full closeout equation so repeated rounding cannot create or erase value. I would include zero rate, maximum duration, overflow operands, and the exact before/at/after liquidation boundary.

Liquidation and repayment also need terminal-state tests: a failed arithmetic check must leave the position untouched, closeout must happen once, and subsequent liquidation or repayment attempts must not emit another success event or alter balances.

This closely matches my merged StreamPay settlement work (#161), where I handled exact end-time/cancellation boundaries and one-time value conservation, plus the stateful financial-invariant suite in Commitlabs-Org/Commitlabs-Contracts#556. I can open a focused draft about 36 hours after assignment.

[ZacLou]

I'd like to work on this issue. I'll review the requirements and open a PR shortly.