feat: bump instance/persistent TTL on all contract entry points

[dimka90]

Add LEDGER_BUMP/LEDGER_THRESHOLD constants (~1 year) and a bump_instance() helper to both campaign-escrow and dispute-resolution storage layers. Every #[contractimpl] function now bumps the instance TTL, and persistent entries (campaign, application, dispute) are extended on both reads and writes via extend_ttl.

Closes #14

[JamesVictor-O]

@dimka90 Good instinct on the problem (persistent entries need TTL bumps or active campaigns can get archived off-ledger) and the instance-bump-in-every-function + bump-on-read pattern is the right shape. Two things before this can merge:

1. CI gates fail as-is. On this branch:

• cargo fmt --all -- --check fails (several reflow diffs in storage.rs/test.rs) — just needs cargo fmt --all.
• cargo clippy --workspace --all-targets -- -D warnings fails with a real error, not a style nit:

  error: this let-binding has unit value
     --> contracts/campaign-escrow/src/test.rs:99:9
  99 |         let _ = super::storage::set_campaign(&env, &campaign);
  

  set_campaign returns (), so the let _ = needs to go — super::storage::set_campaign(&env, &campaign); on its own.

2. The constant doesn't actually achieve what the PR (and issue #14) set out to do. LEDGER_BUMP = 535_680 is documented as "~1 year — the maximum the Stellar network allows." At 5s/ledger, 535,680 ledgers is ~31 days, not a year — and it's barely different from the 518,400 (~30 days) it replaces. I checked soroban-env-host's own reference network config (soroban-env-host-27.0.0/src/testutils.rs): max_entry_ttl: 6_312_000, which is ~365 days at 5s/ledger. So the real protocol max is roughly 12x larger than what's used here.

This isn't just a doc nit — issue #14's own motivating example is a campaign with a 90-day content deadline silently expiring. A ~31-day bump doesn't protect that campaign if it sits untouched for a month, which is exactly the failure mode the issue is about. (For what it's worth, the issue text itself has the same wrong math in its suggested snippet — this isn't something you introduced, just something worth catching rather than copying through.)

Suggest bumping LEDGER_BUMP to something close to the real ~1-year max (e.g. 6_312_000, leaving headroom under the actual max_entry_ttl) and fixing the comment to match. Happy to re-review once that's in — the rest of the plumbing (where the bump calls are placed, the read-path extension in get_campaign/get_dispute) looks right.