security(frontend): normalize API and wallet errors without leaking sensitive data

[arisu6804]

Problem

Raw provider responses or server details can leak account data and cause unsafe retry decisions.

Objective

Deliver a production-quality improvement to client error boundary and mutation error handling that creates measurable value for correctness, security, reliability, performance, or maintainability.

Implementation scope

• Map errors to stable safe codes and retryability; redact addresses/tokens where appropriate; retain protected correlation data only for diagnostics.

Acceptance criteria

• No secret or raw provider payload reaches user-facing content; retry actions match the normalized error policy.

Required validation

• Malformed-error, redaction, retryability, and correlation tests.
• Existing tests and CI remain passing.
• Add regression coverage for the original failure mode.
• Do not weaken, delete, or skip unrelated tests to obtain a green build.

PR quality bar

• Keep the PR focused and explain design tradeoffs, compatibility impact, and test evidence.
• Avoid typo-only, documentation-only, cosmetic-only, or unrelated refactor submissions.

Out of scope

• Broad rewrites not required by the acceptance criteria.
• Changes to unrelated services, contracts, or user flows.

[isaacsamual994-lang]

I'd like to take this on. I reviewed the frontend service boundary and current Vitest setup, and I'd keep the change focused: introduce one normalized error shape with stable safe codes, retryability, and protected correlation metadata; redact Stellar addresses, token-like values, and raw provider payloads before anything reaches user-facing UI; map wallet rejection separately from transient/retryable failures; and update mutation/error handling to consume that policy. I'd add targeted tests for malformed errors, redaction, retryability, correlation handling, and the original leak/retry failure mode, then run the full test, lint, and build checks. I would not expose secrets or broaden this into unrelated flows.

[grantfox-oss]

🦊 GrantFox — @isaacsamual994-lang has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

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

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@isaacsamual994-lang's PR #290 was approved and merged by @arisu6804.

🏆 @isaacsamual994-lang: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (153 total points). Track your full progress on GrantFox.

👏 Great work, @isaacsamual994-lang! Keep contributing to RemitFlow.