TypeScript SDK: route websocket errors on established connections to onDisconnect

[sephirith]

Description of Changes

Fixes #5706.

The TypeScript SDK's ws.onerror handler treats every websocket error as a connect failure: it sets isActive = false and emits connectError, even when the connection was already established. On an established connection this fires onConnectError (documented as a connect-time failure callback and commonly wired to boot-time auth recovery), silently disables the outbound send path while the socket may still be OPEN (reducer and procedure calls queue with no disconnect to trigger reconnect logic), and loses the error entirely if onclose eventually arrives, since the disconnect emit carried no error argument.

This change tracks whether the initial connection succeeded (InitialConnection received, onConnect invoked). A websocket error after that point no longer emits connectError; instead the error is recorded and the socket is closed, so the existing onclose path emits disconnect and every consumer's existing reconnect handling takes over. The recorded error is passed through to the disconnect emit, which honors the documented onDisconnect contract ("If the connection ended because of an error, the error is passed to the callback"). Errors before the initial connection succeeds emit connectError exactly as before.

API and ABI breaking changes

None. onDisconnect callbacks already accept an optional error argument (error?: Error | undefined); passing the error is additive and matches the documented behavior. Pre-connect connectError behavior is unchanged.

Expected complexity level and risk

1 - two private fields and a gate in one method. The only behavioral change is on a code path that previously produced a silently stalled connection routed to the wrong callback; it now produces a socket close, which flows through the disconnect handling every consumer already has.

Testing

• npm test in crates/bindings-typescript passes (289 tests, 29 files).
• prettier --check passes on the changed file.
• Manually verified the failure mode in production (Tidefall, spacetimedb@2.7.1): a mid-session websocket error previously fired our onConnectError login-recovery path while reducer calls silently queued and no reconnect ran; with this routing the socket closes, onDisconnect fires with the error, and the client reconnects normally.

[sephirith]

@bfops @JasonAtClockwork - Thanks for merging in my last PR. Another small but important one here. Could you please review and merge?