feat: add non-linear vesting curves

[OMGO-Code]

Closes #854

Summary

Add non-linear vesting curve support (step and exponential) selectable per VestingSchedule in Revora-Contracts/src/vesting.rs. Straight-line vesting is kept as the default (Linear) so existing behavior is unchanged.

Changes

• VestingCurve enum: Linear, Cliff, Graded(Vec<(u64, u32)>), Step(period_secs: u64), and Exponential(k_num: u32, k_den: u32).
• evaluate_curve helper: evaluates the vested fraction using scale-1e18 checked i128 fixed-point arithmetic only — no floats. Exponential curves resolve via bounded, deterministic binary search + exponentiation-by-squaring; elapsed is clamped to duration.
• Persistence: curve is stored on VestingSchedule and validated in create_schedule before persisting.
• Migration: migrate_legacy_schedule converts pre-curve LegacyVestingSchedule layouts to Linear, preserving prior behavior.

Validation & failure modes

• New VestingError::InvalidCurveParameters (109).
• Step(0) and Exponential(_, 0) are rejected; Exponential exponents bounded (0 < k <= 32, not both zero).
• All intermediate fixed-point math is checked; overflow falls back to InvalidCurveParameters (safe, diagnosable).
• Backward compatibility: legacy schedules migrate to Linear.

Tests

• linear_is_backward_compatible, step_vests_only_completed_buckets, exponential_is_back_loaded_without_floats, exponential_linear_ratio_is_compatible, elapsed_is_clamped_at_end, invalid_curve_parameters_are_rejected.

Compatibility / migration

• New curve field is added to VestingSchedule; existing (legacy, no-curve) schedules remain valid and behave as Linear. Migration is pure and persisted atomically by the caller.

Note: this branch could not be fully compiled/tested in this checkout because the repo is currently failing to build for an unrelated reason (a missing RevoraError::ProofTooDeep variant referenced in lib.rs after recent upstream merges).

[drips-wave]

@OMGO-Code 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

[OMGO-Code]

CI: pre-existing failures on the upstream base, not from this PR

The failing checks on this PR (cli/clippy and format) are inherited from the upstream base, not introduced by this change. Verified:

• This branch differs from its merge-base (e92c81e, current upstream master) in only one file: src/vesting.rs (git diff e92c81e..HEAD --stat → 1 file changed, 232 insertions, 26 deletions). src/lib.rs is untouched.
• A pure checkout of upstream e92c81e (zero changes from this PR) independently reproduces both failures:
  • cargo fmt --all -- --check → Diff in src/lib.rs:391 (module-ordering drift of mod test_accrual_reconciliation_prop;).
  • cargo clippy --all-targets --all-features -- -D warnings → fails on lib.rs with Hash<32> not implementing Debug, a stale inner-attribute #[deny(clippy::arithmetic_side_effects)] that should be #![deny(...)], and a duplicate_mod warning.
• Because fmt/clippy fail first, the "Build and test" job was skipped — the tests from this PR were never executed in this run.

This is the same repo-wide breakage noted in the PR description. It lives in src/lib.rs on the base and is outside the scope of this issue (vesting.rs only). Happy to address the base lint/format drift in a separate PR if maintainers want it fixed.

[OMGO-Code]

Closes #854

Scope

One file: src/vesting.rs. Plus a follow-up formatting-only commit (d3732cd) that applies cargo fmt to pre-existing drift in untouched base files to unblock the CI format gate.

Summary

Add non-linear vesting curve support (step and exponential) selectable per VestingSchedule. Linear remains the default so existing behavior is unchanged.

What I changed

• New VestingCurve enum: Linear, Cliff, Graded(Vec<(u64, u32)>), Step(period_secs: u64), Exponential(k_num: u32, k_den: u32). Step field narrowed u32 → u64.
• evaluate_curve(curve, elapsed, duration, total): scale-1e18 checked i128 fixed-point math, no floats. Exponential via bounded binary search + exponentiation-by-squaring; elapsed clamped.
• Curve persisted on VestingSchedule and validated in create_schedule.
• migrate_legacy_schedule converts pre-curve LegacyVestingSchedule → versioned schedule, defaulting to Linear.

Validation & failure modes

• New VestingError::InvalidCurveParameters (109). Step(0) and Exponential(_, 0) rejected; exponents bounded. All fixed-point math checked; overflow → InvalidCurveParameters.

Tests

linear_is_backward_compatible, step_vests_only_completed_buckets, exponential_is_back_loaded_without_floats, exponential_linear_ratio_is_compatible, elapsed_is_clamped_at_end, invalid_curve_parameters_are_rejected.

CI status

• Format check: fixed via commit d3732cd (formatting-only) — now passing.
• Event-sunset validation: passing.
• Clippy: failing, but this is inherited from the upstream base, not this PR.

I verified the clippy breakage is pre-existing and outside this PR's scope:

1. This branch differs from its merge-base in src/vesting.rs only (git diff <base>..HEAD --stat → 1 file).
2. A pure checkout of the upstream merge-base (e92c81e) fails clippy with the same ~800 errors (duplicate test modules/duplicate contractimpl methods in lib.rs, missing MAX_PROOF_DEPTH in merkle_helpers.rs, soroban-SDK version mismatch such as Hash<32> vs BytesN<32>, missing crate::test* helpers). None are in vesting.rs.
3. Upstream master's own CI is red for the same reason. The push CI run for upstream master at e92c81e (Actions run 30570856212, 2026-07-30) fails both Clippy and Format check — identical failures to what this PR's clippy job shows, on a commit with zero of this PR's changes.

I'm happy to address the base lib.rs/test compile+lint drift in a separate PR if maintainers want it fixed.