feat: add structured error classes for validation and payment failures

[mehmetkr-31]

Summary

Closes #224

Introduces ValidationError and PaymentError custom error classes that replace generic Error throws with structured, actionable error messages.

What changed

• New file: core/error/sdkErrors.ts — ValidationError (field, providedValue, expectedFormat) and PaymentError (code, retryable flag)
• validation.ts — All validation errors now include what was provided, what was expected, and which field failed
• sendUserOpAndWait.ts — Payment errors now include error codes (USER_OP_FAILED, NO_TX_HASH, EXECUTION_FAILED) and retryability hints

Before

Error: Invalid amount: must be a valid number
Error: User operation failed: 0xabc...

After

ValidationError: Invalid amount: "abc" is not a valid number
  → field: "amount", expectedFormat: "a positive decimal number (e.g. '10.50')"

PaymentError: charge user operation was rejected on-chain (hash: 0xabc...)
  → code: "USER_OP_FAILED", retryable: true

Why this matters

• Developers can programmatically handle errors via instanceof ValidationError
• Error messages tell users what went wrong and how to fix it
• retryable flag enables automatic retry logic in consuming applications

Test plan

• All 183 payment + error tests pass
• New tests for ValidationError field metadata
• Lint passes (yarn lint)
• Build passes (yarn build)

🤖 Generated with Claude Code

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[mehmetkr-31]

Closing in favor of #267 which expands on this work — propagating the structured error classes across the entire payment module (10 files, 18 error sites) instead of just introducing the classes.