Make the AsyncOperationsPanel a live submission queue driven by real contract operations

[Baskarayelu]

📋 Description

components/AsyncOperationsPanel.tsx and components/AsyncSubmissionStatus.tsx render the contract-progress UI on app/split/page.tsx, but the stages and queue (splitStages, splitQueue) are hardcoded sample arrays. The panel is meant to be a live "stack" of in-flight contract submissions (build → sign → submit → confirm).

This issue introduces a small operations store so the panel reflects real async operation state.

Why this matters: async contract operations (sign + submit) take 15–45s. Users need a persistent, truthful queue showing what's pending, signing, or confirmed — not a static demo list.

🎯 Requirements & Context

Functional requirements

• Add an operations store (context or a store under lib/context) tracking operations with status: building | awaiting-signature | submitting | confirmed | failed.
• Drive AsyncOperationsPanel queue items from the store instead of splitQueue.
• Cap visible cards at three (newest highest), per the existing design note, and collapse inline on mobile.
• Wire AsyncSubmissionStatus pending from the active operation.

Context & constraints

• Reuse existing Tailwind tokens; no new colors.
• Keep the complete items visible briefly then drop.

🛠️ Suggested Execution

git checkout -b feat/async-operations-store

• Add the store, refactor the panel to consume it, add TSDoc, add a Vitest test for the store reducer/transitions.

npm run lint
npx tsc --noEmit
npm run test:coverage
npm run build

• Edge cases: more than three concurrent ops, a failed op, signature rejected, op completes while another starts, reduced motion, mobile inline collapse.
• a11y: status changes announced via aria-live.

Example commit message

feat(async): drive AsyncOperationsPanel from a live operations store

Replaces hardcoded splitStages/splitQueue with a status store
(building/signing/submitting/confirmed/failed) capped at three cards.

✅ Acceptance Criteria & Guidelines

Requirement	Target
Operations store with status transitions	Required
Panel + status driven by store	Required
Three-card cap + mobile collapse	Required
Store test coverage	≥ 90%
Accessibility + responsive + lint + build	Required
Timeframe	96 hours from assignment

💬 Community & Support

Join the RemitWise contributor community on Discord: https://discord.gg/CtQuPZFMA

Comment to claim before starting. 🚀

[Menjay7]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. Thank you!

[jaynomyaro]

Hi! I’m a full-stack developer with a strong blockchain background. I’d love to handle this issue and can deliver a clean, reliable solution. Kindly assign it to me.

[jaynomyaro]

Hi! I’m a full-stack developer with a strong blockchain background. I’d love to handle this issue and can deliver a clean, reliable solution. Kindly assign it to me.

[ekwe7]

I would love to work on this issue. I have experience building production ready applications and collaborating through GitHub workflows. I'll carefully analyze the current implementation, propose a reliable solution, and submit a well-tested PR. My focus is on clean code, maintainability, and timely delivery

[Senorespecial]

I would like to work on this issue please assign

[grantfox-oss]

🦊 GrantFox — @Menjay7 has been assigned to this issue!

Next steps:

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

Good luck! Track your progress on GrantFox.