Fix/milestone state machine

[onyekachi66]

Closes #1152

Description

This PR addresses the production-quality risk area concerning milestone progress and fund-release state handling. By introducing a definitive local state machine, we enforce strict invariants across retries, page refreshes, and interrupted wallet operations, preventing contradictory client state from displaying impossible transitions.

Refs #

Acceptance Criteria Addressed

• Enforces invariants for normal and adversarial inputs: The state machine operates within MilestoneTracker and FundReleaseStatus, consuming validated server state and applying optimistic UI updates defensively. The inputs rely strictly on the vault context and authorized bounds.
• Defines the state machine for every success, rejection, cancellation, and retry path: Implemented useVaultActionStore leveraging Zustand. The explicit ActionStatus mappings (idle | signing | submitting | success | error) map precisely to real on-chain operational phases.
• Prevents duplicate submissions and stale responses: Used optimistic updates on successful actions. If an action locally succeeds (success), the UI immediately marks the milestone as validated (optimistically), preventing the user from clicking the action button again while the server or indexer is lagging.
• Failure recovery that preserves user intent: The state is persisted via sessionStorage. If a timeout or server error occurs post-signature (during submitting), the user is presented with a "Retry" prompt directly inline on the milestone. This retry bypasses the signing phase, safeguarding against silently repeating an on-chain action or prompting unnecessary wallet signatures.
• Automated tests: Updated unit tests for MilestoneTracker and FundReleaseStatus to simulate and assert optimistic UI state injections and deterministic conditional rendering of loading and error UI inline.

Validation Commands

To validate the implementation and run tests, use:

# Verify type correctness
pnpm tsc --noEmit

# Run unit tests associated with the feature
pnpm vitest run src/components/__tests__/MilestoneTracker.test.tsx

Design Tradeoffs & Limitations

• Optimistic State Lifespan: We are relying on sessionStorage (via Zustand persist) for the UI action store to ensure that refreshes during long-running submissions preserve state. This means state will not survive a full browser tab close, which is a conscious tradeoff to prevent endless zombie states since we cannot indefinitely poll the indexer without an active session context.
• CI Failures: None expected, though if the overarching VaultDetail integration tests expect the "Validate Milestone" button to reside at the header layout instead of within the <MilestoneTracker> elements, those DOM locators might need a minor selector update in subsequent QA passes.

---

[drips-wave]

@onyekachi66 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits