[Contracts] Persistent fund-bearing and record storage entries are created without extend_ttl

[david87131]

Why this matters

Several contracts persist critical entries without extending TTL, so they can be archived. In escrow, EscrowStorage::save, add_approval, increment_approval_count and add_release_record never call extend_ttl, so a funded escrow can be archived before a 14-day timeout and freeze funds. In dispute_resolution and the chioma contract, instance State/TimeoutConfig TTL is only bumped at initialize/config writes, so the admin/state entry can be archived while per-record entries are kept alive, causing reads to fail with NotInitialized. update_metadata and royalty/payment writes also omit TTL bumps.

Acceptance criteria

• All persistent entries that must outlive their operation window call extend_ttl on create and update, sized to the maximum expected lifetime
• Instance storage holding contract State is re-extended on state-reading/mutating entrypoints, not only at initialize
• A consistent TTL constant/helper is used across the workspace and documented
• Tests advance the ledger past a typical timeout and assert the escrow/agreement remains readable and operable

Files to touch

• contracts/escrow/src/storage.rs
• contracts/dispute_resolution/src/lib.rs
• contracts/chioma/src/agreement.rs

Out of scope

• Automatic TTL-renewal keeper
• Changing storage classes

[david87131]

Superseded by the consolidated contract audit issues (#67-#104) which cover the same findings more comprehensively. Closing to avoid duplicate coverage.

[444notdotun]

hi, i would love to work on this project

[Vyacheslav-Tomashevskiy]

Submitted a fix in #229 — adds extend_ttl to all persistent escrow/dispute entries and re-extends the instance State TTL on every read/mutate entrypoint (consistent documented constants), with two ledger-advance tests proving the funded escrow and admin/state stay readable past their window. All four acceptance criteria addressed; cargo test/fmt/clippy green.