Improve Soroban and network error messaging with human-readable diagnostics

[gracious01-tech]

Description

This PR improves the way Soroban RPC and network failures are surfaced to users by replacing raw, opaque error strings with clearer, more actionable messages.

Summary

Soroban RPC responses often return terse codes such as tx_bad_seq, contract_error, and auth_revoked, which are difficult for end users and even many integrators to interpret. The current implementation was exposing these raw values directly, leading to confusing toast notifications and unnecessary support escalations for issues that are often straightforward to resolve.

This change introduces a structured error-resolution layer in errors.ts that translates known Soroban and network error patterns into user-friendly messages, classifies the severity of errors, and prepares them for display in the UI.

What changed

• Added a comprehensive SOROBAN_ERROR_CODES dictionary with more than 15 known Soroban error substring mappings.
• Added NETWORK_ERROR_KEYWORDS for common JavaScript and browser-level network failures, including fetch, websocket, timeout, DNS, abort, and connection reset scenarios.
• Implemented resolveSorobanError(rawError: string) to:
  • normalize the input to lowercase,
  • match known keywords and substrings,
  • fall back to network-related guidance when appropriate,
  • and wrap unknown failures with a generic, user-safe message.
• Implemented classifyError(error: unknown) to assign:
  • severity: low, medium, or high
  • actionability: true or false
• Implemented formatErrorForDisplay(error: unknown) to prepend severity tags for UI display.
• Added unit tests in errors.test.ts to cover:
  • known Soroban mappings,
  • network fallback behavior,
  • severity classification,
  • and display formatting.

Why this matters

This improves the user experience in a few important ways:

• Users receive clearer, more helpful error messages instead of cryptic protocol codes.
• Actionable issues such as authentication problems, insufficient funds, and timeouts are clearly identified.
• The UI can present a consistent severity level, making error handling and toast presentation more meaningful.
• This reduces confusion and lowers the chance of users opening support requests for preventable issues.

Verification

Verified locally with:

• npx vitest --run tests/unit/errors.test.ts

Result:

• 1 test file passed
• 9/9 tests passed

Closes #9

[elizabetheonoja-art]

LGTM