[Quality][Medium] Add offline and reconnect guards to financial mutation flows

[Baskarayelu]

Objective

Detect connectivity transitions, freeze unsafe automatic retries, and route ambiguous operations through the existing reconciliation state machine.

Why this matters

A network transition during a financial mutation can leave the UI showing a retryable failure when the operation may already have reached the provider or chain.

This is a substantive production-quality improvement. It must change runtime behavior, security guarantees, correctness, reliability, or meaningful user functionality. It is not a documentation-only, formatting-only, or trivial dependency task.

Scope

Area: offline resilience

Starting points: lib/client/widgetFetchRetry.ts, lib/soroban/client.ts, useTransactionStatus.ts, components/AsyncSubmissionStatus.tsx

The contributor should verify the current implementation before changing it and keep the PR limited to this issue. Do not introduce unrelated refactors or weaken existing CI/security gates.

Acceptance criteria

• Connectivity loss stops unsafe automatic retries for non-idempotent operations.
• Reconnect triggers status reconciliation rather than blind resubmission.
• The user sees whether the operation is pending, unknown, or safe to retry.
• Offline state does not clear the canonical operation identity or expose stale success.

Required validation

• Test loss before signing, during submission, after submission, and during polling.

• Test reconnect with confirmed, failed, and unknown provider outcomes.

• Add a browser E2E test using controlled network conditions.

• The PR explains the failure mode, the chosen design, backward-compatibility impact, and rollback or migration considerations.

• The PR includes CI evidence and does not contain secrets, generated noise, unrelated cleanup, or disabled checks.

Contributor deliverables

• Open a focused feature branch and do not begin implementation until assigned.
• Reference this issue with Closes #<issue-number> or Fixes #<issue-number>.
• Check off every acceptance criterion in the PR with links to the relevant code and tests.
• Include a security/correctness note explaining why adversarial inputs cannot bypass the new guarantee.

Maintainer quality bar

The PR must be independently reviewable, preserve existing behavior outside this scope, exercise failure paths, and pass the repository's complete required CI/CD checks. Reward eligibility is not guaranteed by this issue or by merging.

[guptakumarranjeet150]

Hello @maintainers,

I can tackle [Quality][Medium] Add offline and reconnect guards to financial mutation flows. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in Remitwise-Org/Remitwise-Frontend
• Implementation: Build [Quality][Medium] Add offline and reconnect guards to financial mutation flows with clean React/Next.js components, responsive styling, and proper loading/error boundaries.
• Testing: Add component unit tests and ensure zero TypeScript/ESLint warnings.
• PR: Atomic commit with clean git hygiene and passing CI

Excited to work on this—please assign to me and I'll submit a clean PR shortly!

[shobhamerabacha-star]

Hey team,

I would love to take this on. My planned approach:

• Build [Quality][Medium] Add offline and reconnect guards to financial mutation flows with clean React/Next.js components, responsive styling, and proper loading/error boundaries.
• Add component unit tests and ensure zero TypeScript/ESLint warnings.

Looking forward to contributing—please feel free to assign!