fix(perps): ensure SDK clients before provider metadata read

[abretonc7s]

Explanation

Stacked on #9032 — merge that first, this targets its branch.

#9032 makes trading actions wait for an in-flight PerpsController.init() instead of failing immediately. Running that branch against HyperLiquid testnet shows the wait works but the action still fails: it now reaches HyperLiquidProvider.placeOrder, which resolves asset info before it ensures trading readiness. That path calls #getCachedMeta → #clientService.getInfoClient() → ensureInitialized(), which throws CLIENT_NOT_INITIALIZED while the SDK clients are still down. #ensureReadyForTrading() (and with it #ensureClientsInitialized()) only runs later in placeOrder.

So on #9032 alone the caller stops getting a thrown error and starts getting { success: false, error: 'CLIENT_NOT_INITIALIZED' } — same failure, quieter.

This adds the missing ensure on the cache-miss path of #getCachedMeta, which is the first client touch on the write path. It is idempotent, and a warm cache hit returns before it, so an initialized provider does no extra work. All 12 #getCachedMeta callers benefit.

Proof

Real PerpsController on HyperLiquid testnet (headless core adapter: real messenger wiring, fixture signer, real transports). Scenario: disconnect() → start init() without awaiting → placeOrder immediately. Order is a resting limit 50% below market (never fills), cancelled by the rig.

Build	Cold-start result
main	rejects, thrown CLIENT_NOT_INITIALIZED
#9032 alone	resolves { success: false, error: 'CLIENT_NOT_INITIALIZED' }
#9032 + this change	order placed (57799146376), cancelled

Executable recipe (perps-cold-start-order.recipe.json, core adapter): asserts verdict: ORDER_PLACED and error: null from the rig. Fails on #9032 alone (cold-start-order.stdout does not contain "verdict": "ORDER_PLACED"), passes with this change. Recipe and rig live in the perps recipe library rather than this repo; happy to share both.

Unit guard: HyperLiquidProvider.trading.test.ts — "brings the SDK clients up before reading asset metadata" makes the mocked getInfoClient throw CLIENT_NOT_INITIALIZED until initialize() runs, then asserts placeOrder succeeds. Red before the change, green after.

Validation

• jest tests/src/providers — 14 suites, 667 passed, 0 failed
• eslint on both changed files — clean
• changelog:validate — clean

References

• Builds on fix(perps): prevent CLIENT_NOT_INITIALIZED during reconnection and cold start #9032

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

---

Note

Low Risk
Narrow, idempotent initialization guard on an existing metadata fetch path; warm-cache behavior unchanged and covered by a focused unit test.

Overview
Fixes a remaining cold-start / post-disconnect CLIENT_NOT_INITIALIZED path on HyperLiquid trading after controller init waits (#9032): placeOrder still resolves asset info (via #getCachedMeta → InfoClient) before #ensureReadyForTrading, so the first metadata fetch could throw or return { success: false, error: 'CLIENT_NOT_INITIALIZED' } while clients were still down.

On cache miss (or skipCache), #getCachedMeta now awaits #ensureClientsInitialized() before getInfoClient(). That call is idempotent; warm cache hits return earlier and do not add work.

Adds a unit test that mocks getInfoClient to fail until initialize() runs, and documents the fix in CHANGELOG.

^{Reviewed by Cursor Bugbot for commit 32e3a60. Bugbot is set up for automated code reviews on this repo. Configure here.}