Jupiter API Client with Resilience Layer

Problem/Feature Description

You are building a shared API client library that multiple services in your organization will use to interact with Jupiter APIs. The library needs to provide a unified, resilient HTTP layer that all Jupiter API consumers can rely on. Different teams use different Jupiter APIs (swaps, orders, pricing, portfolio), so the client must be generic enough to work across all of them.

The key requirements are:

• A generic request function that handles authentication, response parsing, and error normalization for all Jupiter endpoints
• A retry mechanism that intelligently decides which errors to retry and which to surface immediately, using proper backoff strategies
• Transaction state management that handles the asynchronous nature of blockchain transactions (a transaction can be submitted but not yet confirmed, or it can fail after submission)
• User-facing error messages that tell the caller what they can do about the error (e.g., "retry later", "adjust your parameters", "check your balance")
• The library needs to handle the fact that some Jupiter API errors use negative numeric codes, some use positive numeric codes, and some use string codes, each meaning different things

The client should be the single source of truth for error handling patterns so that individual service teams don't have to re-implement this logic.

Output Specification

Produce a single TypeScript file called jupiter-client.ts that exports:

1. A JupiterClient class (or set of functions) with a generic request<T>(path: string, options?: RequestOptions) method
2. A withRetry<T>(action: () => Promise<T>, options?: RetryOptions) function implementing the retry strategy
3. A classifyError(error: any) function that normalizes any Jupiter error into a structured format
4. A TransactionTracker class or set of functions for tracking transaction states (submitted/confirming/confirmed/failed)
5. A toUserAction(error: StructuredError) function that maps errors to actionable user-facing messages
6. Type definitions for all error types, result types, retry options, and transaction states

The code should use the native fetch API. It does not need to compile or run -- focus on correct error classification logic, proper retry semantics, and comprehensive state tracking.