[GrantFox][High] Implement a complete wallet transaction state machine

Summary

Implement a complete wallet transaction state machine

Why this matters

Prediction actions need explicit signing, submission, confirmation, rejection, timeout, and retry states.

Scope

Create a reusable lifecycle model and prevent duplicate market mutations.

Acceptance criteria

• Every action exposes deterministic lifecycle states.
• Confirmed actions cannot be submitted twice.
• Rejection differs from network failure.
• Tests cover refresh, disconnect, retry, and duplicate clicks.

Validation

Add regression coverage for existing behavior, failure modes, authorization boundaries, and compatibility. The implementation must pass the repository CI checks.

Non-goals

• Typo-only, formatting-only, or documentation-only changes.
• Unrelated refactors or dependency upgrades.
• Weakening existing security, authorization, CI, or production safeguards.

Contributor application

Before implementation, comment with relevant experience, a 1–4 bullet approach, and an estimate for opening the first draft PR. Wait for maintainer assignment before coding.

PR requirements

Use a feature branch, include Closes #<issue-number>, check every acceptance criterion, link criteria to code/tests, explain security and failure-mode considerations, and pass CI.

Reward-readiness

This is a substantive GrantFox campaign issue. Merge and CI success do not by themselves guarantee reward eligibility; final reward-readiness is determined by campaign review.

No files, tests, or entry points are named. Start by locating the wallet transaction handling, market mutation logic, and existing regression tests, then map the lifecycle states and failure modes to the acceptance criteria. Done means deterministic action states, duplicate-submission prevention, distinct rejection and network-failure handling, and coverage for refresh, disconnect, retry, and duplicate clicks.