Soroban Storage TTL Bump Management

[Kingsman-99]

Description

Soroban persistent storage entries expire after a network-defined number of ledgers unless their TTL is explicitly extended via bump calls; without proactive TTL management, invoice state can silently disappear mid-campaign and make escrowed funds irrecoverable. The contract needs a systematic bump strategy tied to every write path, plus a public entry point allowing anyone to extend a live invoice's TTL.

Technical Context

contracts/split/src/storage.rs — centralize all persistent writes in save_invoice(), save_recipients(), and save_contributor() helper functions; each helper calls env.storage().persistent().bump(key, MIN_INVOICE_TTL_LEDGERS, MAX_INVOICE_TTL_LEDGERS) immediately after set(); contracts/split/src/constants.rs — define MIN_INVOICE_TTL_LEDGERS: u32 and MAX_INVOICE_TTL_LEDGERS: u32 with inline comments documenting the rationale; contracts/split/src/lib.rs — add bump_invoice_ttl(invoice_id: u64) entry point callable by any address.

Acceptance Criteria

• Every env.storage().persistent().set() call in save_invoice(), save_recipients(), and save_contributor() is immediately followed by a bump() call using the constants from constants.rs
• MIN_INVOICE_TTL_LEDGERS and MAX_INVOICE_TTL_LEDGERS are defined in contracts/split/src/constants.rs with documented rationale for the chosen ledger counts
• bump_invoice_ttl(invoice_id) bumps all DataKey entries associated with the given invoice and returns Error::InvoiceNotFound for unknown IDs
• No direct env.storage().persistent().set() calls exist outside of the centralized storage helper functions (enforced by a grep-based CI check in the Makefile or CI script)
• A test in contracts/split/src/tests/ttl_tests.rs confirms that bump() is invoked with the correct key and minimum TTL value after each storage write
• All CI checks (cargo build --target wasm32-unknown-unknown, cargo test, cargo clippy) pass and the branch has no merge conflicts

---