fix(perps): read order-path data over HTTP during a WebSocket reconnect

[abretonc7s]

Explanation

Stacked on #10589. Draft until a transport stress test confirms that always reading over HTTP is the right long-term policy for the order path. The alternative is a WebSocket-first policy with HTTP fallback.

Pre-order reads depend on the WebSocket. During a reconnect, HyperLiquidClientService clears its WebSocket info and subscription clients and keeps the HTTP exchange and HTTP info clients. getInfoClient() without { useHttp: true } requires the WebSocket clients, so several reads on the order path threw CLIENT_NOT_INITIALIZED:

• the #ensureReady gate and asset-map rebuild
• unified-account and referral setup
• HIP-3 DEX balances and spot metadata
• the margin-mode lock (open orders, TWAP history, active asset data)
• the open-order read in updatePositionTPSL

These reads now go over HTTP, like the metadata, price, position and builder-fee reads already did.

getMaxLeverage capped orders at 3x during a reconnect. It required the WebSocket clients before an HTTP metadata read, and its error path fell back to the 3x default. Orders above 3x were then rejected with ORDER_LEVERAGE_INVALID. The WebSocket gate is removed.

Pre-order reads fail on a transient 429. These reads share HyperLiquid's per-IP REST budget with charts and history. They now retry a 429 up to twice with jittered exponential backoff, at most about 1.5 s: metadata, prices, spot metadata, positions and balances, open orders, TWAP history and asset data. Other errors are not retried. Setup reads and exchange writes are not retried.

Trade-offs to settle before this leaves draft:

• Every order uses these HTTP reads, not only orders placed during a reconnect.
• Mobile HTTP has its own failure modes: nitro-fetch aborts and Cronet errors (TAT-3871).
• More of the per-IP REST budget is used, plus retries during a rate limit.

Reproduction

I ran the real headless PerpsController, SDK transports, signer and BTC resting-limit-order path against HyperLiquid testnet. The fault was introduced at the SDK fetch boundary or the WebSocket transport, and each scenario was run on unfixed source and then on 9eb852d, which contains this change.

Controlled condition	Unfixed source	With this change
One HTTP 429 on pre-order allMids (ecbc4e9)	placeOrder returned 429 Too Many Requests.	The retry reached testnet and got HTTP 200. Order 61421338052 was observed open, then canceled.
Replacement WebSocket delayed 8 s during provider.reconnect() (merge-base 1f15b7c)	An order submitted while connecting returned CLIENT_NOT_INITIALIZED.	Order 61421532628 succeeded while the reconnect was still pending. It was observed open, then canceled by ID.

The 429 was a constructed response. These faults did not occur organically, and no Mobile or Extension UI was exercised.

Validation

• Provider, controller and utils suites: 51 passed, 2669 passed.
• The TAT-4041 provider tests fail with CLIENT_NOT_INITIALIZED when these source changes are reverted. A per-site check reverted each changed read on its own, and a test caught every one.
• 9 unit tests for the retry helper. rateLimitRetry is not exported from the package.

References

• Stacked on fix(perps): wait for the client's init() across a disconnect-then-init reconnect #10589
• Related to TAT-4041, TAT-3871

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them