Distinguish V1 WebSocket execution errors

Follow-up from https://github.com/clockworklabs/SpacetimeDB/pull/5640. We should audit the errors entering MessageExecutionError to preserve classification to distinguish between module/guest errors from lifecycle or internal database failures.

Details

In [crates/client-api/src/routes/subscribe.rs] around line 852, we have the following block:

...
    while let Some((data, timer)) = recv_handler.next().await {
        let result = message_handler(data, timer).await;
        if let Err(e) = result {
            if ws_version == WsVersion::V1
                && let MessageHandleError::Execution(err) = e
            {
                // TODO: Review log level after guest/client execution errors can be distinguished from internal failures.
                log::warn!("{err:#}");
                // If the send task has exited, also exit this recv task.
                if unordered_tx.send(err.into()).is_err() {
                    break;
                }
                continue;
            }
...

Currently using warn! as a conservative default. It appears that this shared error path will combine invalid reducers/reducer arguments, invalid one-off queries with internal worker or database failures. If we can maintain a classification we can more appropriately change the logging behaviour.

Start in crates/client-api/src/routes/subscribe.rs around line 852, then trace MessageExecutionError and MessageHandleError::Execution through the WebSocket message path. Audit where module or guest errors are combined with lifecycle, worker, or database failures; done means those categories remain distinguishable so the logging behavior can be adjusted appropriately.