[Feature] V2: implement TTL policy for all v2 record types

[collinsezedike]

Summary

V1 only has one long-lived record type per assertion. V2 has four (AssertionV2, Resolution, Position, Credit, see #64/#66/#69), and updating the assertion alone does not keep its separate Position/Credit entries alive. This issue implements TTL coverage and a restoration path for all of them.

What to build

• Each record type gets a TTL long enough to cover its own maximum active-phase horizon (registration duration + anti-sniping hard max + reveal duration for Position, plus a pinned settlement/withdrawal grace period on top for Credit) as sized in PolicySnapshotV2 (see [Feature] V2: implement PolicySnapshot and versioned assertion state #64).
• Since Position and Credit keys are not enumerable on-chain (per the design's explicit avoidance of an unbounded voter vector), a caller who knows a specific (id, address) key must be able to bump or restore that entry's TTL/archival state permissionlessly. A withdrawal or settlement call should itself extend TTL as a side effect of touching the record.
• If a record is archived (expired past its TTL) before its owner withdraws, there must be an explicit restoration path: the assertion, its Resolution, and any Position/Credit entries tied to it must be restorable before settlement or withdrawal can proceed. The liability is not extinguished by expiry, restoring the record must always be possible for as long as unpaid credit exists against it.
• v2 must emit indexable events for position funding/top-ups, eligibility freeze (W), every reveal, outcome lock/finalization, settlement/credit accrual, and withdrawal (see [Feature] V2: implement reveal phase and commitment verification #67-[Feature] V2: implement credit accrual and owner-authorized withdrawal #70), specifically so an off-chain indexer can reconstruct which keys need restoring without on-chain enumeration. Confirm each of those issues actually emits its event before closing this one.

Depends on

#64, #66, #67, #68, #69, #70 (needs the record types and events those issues define).

[shepherd-001]

Hello maintainer, I have reviewed the task, and I am confident I can resolve it. Please assign the task to me.

[grantfox-oss]

🦊 GrantFox — @shepherd-001 has been assigned to this issue!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #72)
2. Your PR will be reviewed by the drydocs maintainers

Good luck! Track your progress on GrantFox.

[collinsezedike]

Assigned, thanks for picking this one up. Happy to answer questions on the design as you work through it.