[T3 Connect] TypeScript SDK: fail the connection instead of crashing Node on a bad message

[bradleyshep]

Part of the work to move T3 Code's T3 Connect relay onto SpacetimeDB.

Description of Changes

Two kinds of error escaped the WebSocket message listener: a server message the client can't decode or apply (for example, client bindings out of step with the module's schema), and an error thrown by a user callback. Browsers only report such errors, but Node rethrows them on the next tick, which kills the host process.

This handles them the way the C# SDK already does:

• A message that can't be applied leaves the client cache inconsistent. The inbound drain now logs it, drops the queued messages and closes the socket, so onDisconnect receives the error like any other failed connection.
• A callback that throws (onInsert, onConnect, onApplied, …) is logged, and the remaining callbacks still run on an open connection. The cache is already up to date by the time callbacks run, so there's no reason to drop the connection. Dropping it would also make the framework providers reconnect, and the same callback would likely throw again on the re-sent rows.

Split out of #6005 / #6006.

API and ABI breaking changes

None.

Rollback safety impact

n/a

Expected complexity level and risk

1. Behaviour changes only for errors that would already have escaped the listener. One visible difference in browsers: a callback error is now logged through the SDK's logger instead of surfacing as an uncaught error.

Testing

• pnpm test in crates/bindings-typescript (324 passing)
• New test: a TransactionUpdate carrying a row one byte short (standing in for bindings out of step with the module) no longer throws from the socket handler; onDisconnect receives the RangeError and the connection closes
• New test: a throwing onConnect callback is logged, a second onConnect callback still runs, and the connection stays open
• Both tests fail against origin/master's SDK code
• The C# precedent: SpacetimeDBClient.cs disconnects when message parsing fails, and Table.cs / SpacetimeDBClient.cs catch and log exceptions from user callbacks
• Limit: closing the connection doesn't settle reducer/procedure promises already in flight; callers still need their own timeouts