fix(sdk): wrap thrown error bodies in real Error so TUI stops rendering [object Object]

[kitlangton]

What this fixes

Since the v1.14.42 Hono → Effect HttpApi migration, opencode HTTP errors that come back with a JSON body (the common case for 4xx — e.g. {name:"NotFoundError",data:{message:"Session not found: ses_x"}}) get thrown by the SDK as raw POJOs, not Error instances. The TUI catches a non-Error object whose `.message` and `.stack` are undefined, and renders `[object Object]` or blank — even though the server provided a perfectly usable message.

Verified empirically (probe in plan mode):

$ POST /session/ses_no_such → 404 {name:"NotFoundError",data:{message:"Session not found: ses_no_such"}}
SDK throws:
  typeof: object
  e instanceof Error: false
  e.message: undefined
  String(e): [object Object]

This is the same family as #26566 (TUI catches undefined .data) and the underlying reason users have been reporting opaque crashes since v1.14.42.

What this PR does

1. Extracts a single shared wrapClientError interceptor in packages/sdk/js/src/error-interceptor.ts.
2. Handles every error body shape: NamedError POJO → message extracted from data.message/message/name; plain object → fallback message; string → wrapped string; empty body / network failure → descriptive Error with method+url+status.
3. Attaches the original parsed body and status under .cause for callers that need structured fields.
4. Wires the same interceptor into both v1 (client.ts) and v2 (v2/client.ts) wrappers — plugins (which import the v1 SDK) get the same treatment as the TUI.
5. Adds packages/opencode/test/server/sdk-error-shape.test.ts with two regression cases against the real in-process server: a 404 with NamedError body, and a 400 with empty body. Verified red→green→red→green during development.

What this PR does NOT change

• Wire shape unchanged. Servers still respond with the same body. Plugins that don't use throwOnError: true (e.g. opencode-gemini-auth, which uses the result-tuple path) are byte-for-byte identical to before. This deliberately stays inside the deferred SchemaErrorMiddleware issue ([BUG on v1.14.42]: Upon trying to start up, non-descript error message is shown #26546 root cause).
• The framework-level HttpMiddleware.logger is already running and already logs the cause server-side — that part is fine and untouched.

Followups

• Fix D (Promise.allSettled in sync.tsx) — small, but needs additional test infra to assert against the bootstrap path. Separate PR.
• Fix E (typed HttpApiError.BadRequest carries a message body) — would surface the cause to clients on top of just status. Larger surface; revisit after observing what opaque cases remain.

Test

• bun run test test/server/sdk-error-shape.test.ts — 2 pass (would fail without wrapClientError)
• bun run typecheck — clean