fix(events): refuse submit and withdraw after winner selection and track updated_at

[rushikeshgarad2024-dev]

Summary of Changes

Closes #131
Reference: docs/threat-model.md v1.0, Tamp.17 (Priority 3).

Problem

Single-release events remain Active until all prizes are claimed. Previously, an applicant could modify or withdraw their submission after WinnersSelected landed. Additionally, submitted_at was preserved across resubmissions without recording when the slot was last modified.

Solution

1. Refuse Writes & Withdrawals After Selection (contracts/events/src/event_ops.rs):
   • In submit and withdraw_submission, check if winners have been recorded or prize claim expiry has been established (storage::winner_count(env, event_id) > 0 || storage::get_prize_claim_expiry(env, event_id).is_some()).
   • Returns Error::WinnersAlreadySelected if attempted.
2. Track Modification Timestamp (contracts/events/src/types.rs):
   • Added pub updated_at: u64 to Submission struct.
   • Populated with current ledger timestamp on initial submit and subsequent resubmissions.
3. Unit Tests (contracts/events/src/tests/hackathon_pillar.rs):
   • Added submit_and_withdraw_after_selection_rejected testing post-selection immutability.
   • Verified updated_at timestamps in resubmit_keeps_original_timestamp_and_updates_uri.

[almanax-ai]

Contract Lifecycle & State: Persistent state decode breakage in Submission

Submission is a #[contracttype] persisted in env.storage().persistent(); adding the new updated_at field changes its serialized layout, so any pre-upgrade stored Submission values may fail to deserialize after upgrade, potentially trapping on reads (e.g., storage::get_submission) and breaking submit/withdraw flows for existing applicants.

Add an explicit storage migration/versioning strategy for existing Submission entries (e.g., store updated_at separately, or make it Option<u64> and treat None as submitted_at, or migrate all stored submissions during an upgrade/init path) before deploying this change to an existing network.

---

Fix with MCP

Almanax found a vulnerability. Can you take a look and fix it?
Finding ID: 92a825b0-4b35-4916-82d3-ba8e39854fbc

Actions

• Reply /almanax ask <question> to ask a follow-up question.
• Reply /almanax dismiss [<reason>] and it won't appear again in future scans.
• Reply /almanax resolve [<reason>] to mark the finding as resolved.
• Reply /almanax severity <level> [<reason>] to override the severity.

[rushikeshgarad2024-dev]

/almanax resolve Made updated_at an Option<u64> (populated as Some(now) on writes) to ensure complete backward compatibility and safe deserialization of any existing pre-upgrade stored Submission entries.