[Quality][High] Improve dashboard chart configuration and memoization: transactional invariants and recovery

[1nonlypiece]

Problem

The current dashboard chart configuration and memoization implementation is a production-quality risk area: Dashboard charts must use one canonical metric definition and avoid stale memoized data when filters or network change.

This issue requires meaningful implementation and focused tests. Typo-only, documentation-only, formatting-only, dependency-only, and cosmetic changes do not satisfy the scope.

Objective

make state transitions deterministic, atomic, and recoverable across retries, refreshes, and interrupted wallet operations for the implementation anchored at src/components/dashboard/chartConfig.ts; src/components/dashboard/HealthMetricsCharts.test.tsx.

Scope

• Establish the feature's explicit state, data, authorization, and failure invariants.
• Define the state machine and invariants for every success, rejection, cancellation, and retry path.
• Prevent duplicate submissions and stale responses from creating contradictory client state.
• Add failure recovery that preserves user intent without silently repeating an on-chain action.
• Keep the change focused on this feature and preserve unrelated public behavior.

Acceptance criteria

• The implementation defines and enforces the relevant invariants for normal and adversarial inputs.
• Define the state machine and invariants for every success, rejection, cancellation, and retry path.
• Prevent duplicate submissions and stale responses from creating contradictory client state.
• Add failure recovery that preserves user intent without silently repeating an on-chain action.
• Automated tests cover success, failure, boundary, retry, and permission behavior applicable to this feature.
• The PR includes validation commands, design tradeoffs, and any remaining limitations.
• The PR references this issue using Refs #<issue-number>.

Priority

High — determined by the potential impact on correctness, user funds or data, security, availability, and implementation depth.

Non-goals

• Do not make typo-only, documentation-only, formatting-only, dependency-only, or cosmetic changes.
• Do not remove tests merely to make CI pass.
• Do not introduce secrets, credentials, unsafe network defaults, or unrelated refactors.

Contributor application

Before starting, comment with relevant experience, a concise implementation approach, the main risks or tradeoffs, and an estimate for opening the first draft PR. Wait for maintainer assignment before coding.

Submission requirements

• Use PR title format: [#<issue-number>] <short summary>.
• Address every acceptance criterion in the PR description and implementation.
• Include focused automated tests and validation results.
• Explain any unavoidable limitations or pre-existing CI failures.
• Address maintainer review feedback before requesting final review.

Quality evaluation will consider scope adherence, implementation quality, test depth, security, correctness, review responsiveness, and follow-up stability.

[drips-wave]

Congratulations, @saitubarde! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @saitubarde: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊