[web] Transport errors hide host error details, making web failures hard to diagnose

[xiejin77]

Summary

When the host returns a non-2xx (e.g. 500) or a network error, the web client throws a generic "transport failure ... HTTP 500" message with no server-side detail, making web failures very hard to diagnose.

Evidence (from the published package)

dsh-client-connection/lib/client.js ~line 6190-6199:

if (!response.ok) throw new Error(`transport failure for ${path}: HTTP ${response.status}`);

The response body (which often contains the actual error / stack) is never read.

Business errors are correctly returned as 200 + { result: { ok: false, error } } and surfaced properly — the gap is only at the transport layer (5xx / network). But in practice web-only problems (picker failures, workspace creation hanging behind a hidden OS dialog, host.openPath issues) are exactly the ones that land here and become undebuggable.

Impact

Web users and maintainers cannot tell why an action failed; they only see a generic HTTP status. Combined with web-specific flows (see the directory-picker discussion), this turns routine failures into black boxes.

Suggested fix

On !response.ok, read await response.text() (or JSON) and append it to the thrown error so the cause propagates to the UI / logs. Optionally include the request path and method.

Happy to PR.