[Quality][Medium] Add storage TTL safety for active economic records

[Baskarayelu]

Objective

Define TTL categories and refresh rules for active versus terminal records, with a bounded cleanup path.

Why this matters

TTL cleanup must reduce storage cost without expiring active bonds, authorizations, or records needed for reconciliation.

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: storage lifecycle

Starting points: docs/storage-ttl.md, docs/TTL_POLICY.md, storage modules

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

• Active records receive TTL extensions before expiry.
• Terminal records are retained for the documented reconciliation window.
• Cleanup cannot remove records referenced by unresolved positions or disputes.
• TTL operations are bounded and idempotent.

Required validation

• Test active, terminal, unresolved, and already-expired records.

• Test cleanup interruption and replay.

• Add storage budget/TTL regression coverage.

• 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.

[guptakumarranjeet150]

Hi maintainers,

I would like to resolve this issue. Here is my proposed execution plan:

• Implementation: Implement [Quality][Medium] Add storage TTL safety for active economic records with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Testing & Verification: Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.
• Delivery: Ready to ship a thoroughly tested PR within 12–24 hours with passing CI.

Ready to deliver a clean, tested PR within 12–24 hours. Please assign!

[shobhamerabacha-star]

Hello! I'd like to work on this issue.

I would like to resolve this issue. Here is my proposed execution plan:

• Implementation: Implement [Quality][Medium] Add storage TTL safety for active economic records with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Testing & Verification: Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.
• Delivery: Ready to ship a thoroughly tested PR within 12–24 hours with passing CI.

Excited to work on this—please assign to me and I'll submit a clean PR shortly!