All persistent storage entries lack TTL management — on-chain data silently expires in production #72

Why this matters now:
The project is entering Phase 3 (formal audit) and Phase 4 (testnet deployment). Soroban persistent storage entries that are never TTL-bumped will be evicted by the Stellar ledger after ~4,096 ledgers (~5–6 days at 5s/ledger). On mainnet this means Completion(task_id, user) guards evaporate (enabling double-claims), Task(task_id) entries vanish mid-campaign, Sponsor(address) entries expire silently un-revoking access control, and Verification(task_id, user) records disappear. None of the three contracts call extend_ttl on any persistent key anywhere in the hot path.

Problem / What:
storage.rs in all three contracts writes persistent keys — DataKey::Task, DataKey::Completion, DataKey::Sponsor, DataKey::Verification, DataKey::UserVerifications, DataKey::LastRewardLedger, DataKey::CidHash, ("balance", addr), ("allow", owner, spender) — without ever calling e.storage().persistent().extend_ttl(key, threshold, extend_to). Instance storage (admin, token, registry, oracles, supply, paused, etc.) is equally unmanaged. The Soroban TTL system will evict any entry whose live-until ledger expires, treating a missing key the same as a key that was never written.

Key Challenges:

• Every mutating function in all three contracts must call extend_ttl on each key it reads or writes — determining the correct threshold/extend-to values for each key class (token balance, task, completion, verification, allowance) requires reasoning about real-world usage patterns and cost.
• Instance storage TTL must be bumped on every external call entry point or the entire contract config (admin, minter, oracle list, paused flag, supply) can vanish.
• TTL constants must be parameterized and auditable — not magic numbers.
• Test coverage must include ledger-sequence advancement to prove entries survive.

Acceptance Criteria:

• Every e.storage().persistent().set(key, val) call in all three contracts is immediately followed by extend_ttl with documented threshold/extend-to constants.
• Every public entry point bumps instance storage TTL via e.storage().instance().extend_ttl(threshold, extend_to).
• Constants PERSISTENT_TTL_THRESHOLD, PERSISTENT_TTL_EXTEND_TO, INSTANCE_TTL_THRESHOLD, INSTANCE_TTL_EXTEND_TO are defined and documented in each contract's storage.rs.
• New tests advance e.ledger().set_sequence_number(PERSISTENT_TTL_EXTEND_TO - 1) and assert all keys remain accessible.
• cargo test --workspace passes with zero failures.

Relevant files/functions:

• contracts/eco-token/src/storage.rs — write_balance, write_allowance, spend_allowance
• contracts/task-registry/src/storage.rs — write_task, mark_completed, add_sponsor, push_creator_task
• contracts/reward-engine/src/storage.rs — write_verification, write_cid_index, push_user_verification_key, write_last_reward_ledger
• All #[contractimpl] entry points in all three contracts (instance TTL bump)

Out of scope: Changing storage key layout, modifying business logic, altering test assertions unrelated to TTL.