fix(perps): wait for the client's init() across a disconnect-then-init reconnect

[abretonc7s]

Explanation

Mobile reconnects Perps with PerpsController.disconnect(), a short cleanup delay, then init(). That covers a foreground resume after a failed ping, and account or network changes. #getActiveProviderWhenReady waited for the disconnect but not for the init() that follows it. An order submitted in that window woke up to an uninitialized controller and failed with CLIENT_NOT_INITIALIZED.

This PR changes only the controller:

• If an action waited on a disconnect() and the controller is still uninitialized afterwards, it waits up to PERPS_CONSTANTS.ConnectionTimeoutMs for the client's init() to start, then runs. If no init() follows, it fails as before. The controller never starts a connection itself.
• If the reconnect switched the selected account, the network or the active provider, the action fails with PROVIDER_LIFECYCLE_STALE instead of running under the new context. The context is recorded when the action is issued.

Behavior change: after a final disconnect with no follow-up init(), an action that was already in flight now takes up to 10 s to fail instead of failing right away. Actions issued after the disconnect are unaffected.

The provider-side part of TAT-4041 (order-path reads over HTTP during a WebSocket reconnect, the getMaxLeverage 3x cap, 429 retry) is split into the stacked draft #10590. It stays in draft until a transport stress test settles the long-term transport choice.

Not in this PR:

• PROVIDER_LIFECYCLE_STALE for an order already in flight inside the provider when the account changes. Continuing under the new account would be wrong. How that code is shown to the user is up to the client.

Reproduction

The real headless PerpsController, SDK transports and signer ran against HyperLiquid testnet, with a client driver calling the real disconnect() and a delayed init().

Controlled condition	Unfixed source (1f15b7c)	With the controller change
Client disconnect() followed by delayed init()	Disconnect finished at 2,970 ms, and the order failed with CLIENT_NOT_INITIALIZED at 2,970 ms. init() only started at 3,470 ms.	init() finished at 5,260 ms. Order 61421723850 succeeded at 7,882 ms, was observed open, and was canceled by ID. 0 BTC orders and 0 positions after teardown.

That run was recorded on 9eb852d, which also contained the provider changes now in #10590. The controller code on this path is the same apart from narrowing: the wait now only follows a disconnect(), not a reinitialization. I have not rerun the testnet reproduction on 9149042. No Mobile or Extension UI was exercised.

Validation (9149042)

• PerpsController suites: 8 passed, 465 passed.
• The 4 new lifecycle tests all fail on main: order placed across disconnect then init, bounded wait, and refusal after an account switch or a network switch. With only the context guard removed, just the 2 switch tests fail.
• oxlint and oxfmt clean; changelog:validate passes; the package build type-checks.

References

• Fixes TAT-4041 (controller part). Provider part: fix(perps): read order-path data over HTTP during a WebSocket reconnect #10590
• Related: TAT-4013 (PROVIDER_LIFECYCLE_STALE on account switch), TAT-3871 (retry and idempotency of the exchange call)

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

[Bigshmow]

I see the connection timeout constant is used in this method invocation but left a comment about using it as a default instead. Otherwise, LGTM.

[Bigshmow]

nit: wdyt about a default for timeoutMs here to inform callers in the future?