Task/centralize storage ttl

[Agbasimere]

Summary

Closes #542

This centralizes persistent-storage TTL policy in storage.rs so TTL behavior is auditable, consistent across write paths, and easier to tune if Stellar rent parameters change.

What changed

• added TTL tier fields to StorageConfig
  • balance_ttl_ledgers
  • market_ttl_ledgers
  • event_ttl_ledgers
  • archive_ttl_ledgers
• introduced shared storage helpers for persistent writes and TTL refreshes
• replaced raw inline TTL literals in persistent write paths
• applied centralized TTL handling to:
  • balances
  • compressed market and market-reference writes
  • event writes
  • creator counter writes
  • archive/migration/config writes
• documented TTL tiers and approximated wall-clock durations in docs/contracts/STORAGE_LAYOUT.md

TTL tiers

• Balance: 535,680 ledgers, about 31 days
• Market: 6,307,200 ledgers, about 365 days
• Event: 1,555,200 ledgers, about 90 days
• Archive: 6,307,200 ledgers, about 365 days

Why

Previously, storage.rs mixed TTL policy into individual write paths, including hardcoded values like 535680. That made archival behavior harder to reason about and easy to drift over time.

Now:

• TTL policy is defined in one place
• persistent writes refresh TTL consistently
• the runtime helper caps requested TTLs to the live Soroban maximum TTL
• tests cover refresh behavior when entries are rewritten near expiry

Files changed

• contracts/predictify-hybrid/src/storage.rs
• docs/contracts/STORAGE_LAYOUT.md

Tests

cargo test -p predictify-hybrid -- storage --test-threads=1
cargo test -p predictify-hybrid --lib -- --test-threads=1

[drips-wave]

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