Contracts: TTL-bump batching strategy for thousands of participant entries (cost/DoS)

[joelpeace48-cell]

Context

campaign/src/lib.rs uses extend_ttl (~16 sites) and rewards ~23 sites. With thousands of
participants each holding persistent entries, naive per-entry TTL bumping becomes expensive and can
exceed ledger resource budgets, while un-bumped entries get archived and break reads. There is a
docs/TTL_STRATEGY.md but no scale test.

Scope

• Define which entries are persistent vs temporary vs instance and document expected rent.
• Batch/lazy TTL extension; consider archival + on-demand restore for cold participants.
• Add a load test simulating 10k participants and measuring TTL/rent cost.

Acceptance criteria

• Documented storage-class decision per entry with rationale.
• Cost model + test for 1k/10k participants.
• No entrypoint exceeds resource limits at target scale.

[Peolite001]

I would love to work on this issue