[Quality][Medium] Prevent stale cache data from overriding fresh financial state

[Baskarayelu]

Objective

Add monotonic response/version handling to the relevant caches and make stale data visibly labeled.

Why this matters

Concurrent refreshes and cache hydration can overwrite fresh balances/status with older responses.

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: client caching and consistency

Starting points: lib/cache/registry.ts, lib/anchor/rates-cache.ts, lib/context/RatesContext.tsx, lib/soroban/client.ts

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

• Older responses cannot replace newer data.
• Cache keys include account, network, asset, and relevant scope.
• Stale fallback is labeled and never used to authorize a mutation.
• Invalidation occurs after successful mutations and on account/network change.

Required validation

• Test out-of-order responses, account switch, network switch, and mutation invalidation.

• Test offline/stale display and refresh recovery.

• Add a deterministic integration test for cache races.

• 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.

[Hollujay]

I would like to work on this issue.

[rupesh-kumar-sah]

Hi everyone,

I can tackle [Quality][Medium] Prevent stale cache data from overriding fresh financial state. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in Remitwise-Org/Remitwise-Frontend
• Core Implementation: Build [Quality][Medium] Prevent stale cache data from overriding fresh financial state with clean React/Next.js components, responsive styling, and proper loading/error boundaries.
• Quality Assurance: Add component unit tests and ensure zero TypeScript/ESLint warnings.

Looking forward to contributing—please feel free to assign!