fix: parse error bodies before throwing on status (R3.7)

[stormer78]

The last two R3.7 violations from the audit. Both silently discard the server's machine-readable error code.

1. register-gateway.ts — the error branch was unreachable

It threw on !res.ok before reading the body, on /trust-tasks — the dispatcher endpoint that emits consent refusals. The file already handled isTrustTaskErrorType, but that branch could never run for a rejected task: rejections arrive non-2xx, and the status check threw first. A consent requirement surfaced as an opaque push/register: ... failed (403): {...} string.

This is the same bug rest-channel.ts was previously fixed for, still live on a second path.

2. rest-channel.ts — R3.7 violated inside the fix for R3.7

res.json() consumes the stream. Both fallbacks then called errorFromResponse(res), whose own res.json() throws Body has already been read into a bare catch {}:

doc = await res.json();                  // consumes the body
...
throw await errorFromResponse(res);      // re-reads it → throws → swallowed

So body?.error?.code was always undefined on that path. The code degraded to a status-only guess, and details/suggestion were always lost — precisely what R3.7 forbids, in the code written to satisfy it.

Adds errorFromBody(body, status, statusText) for callers that have already parsed. errorFromResponse is unchanged for callers that have not.

Why decodeTrustTaskHttpReply was extracted

When I mutation-tested fix 2 by restoring the double-read, no test failed. The reply decoding was only reachable through the full bearer handshake, so it was unverifiable in place.

It encodes a security-relevant decision — whether a refusal keeps the details an approver renders a consent prompt from — and logic reachable only via a DIDComm authcrypt round-trip is logic that in practice never gets exercised. Extracting it made the bug detectable.

A note on the existing tests

The register-gateway tests used { ok, json } object literals rather than real Response objects, so they broke against a change that is correct for every real Response. A hand-rolled stub only implements whatever the code happened to call when it was written. Switched to real Response objects — I hit the same trap in my own wiring test from #98 and fixed that too.

Verification

12 new tests across vta.errors, vta.rest-reply and device.register-gateway, covering: details surviving a 403 refusal, a server code that disagrees with its status, non-JSON bodies on 2xx vs non-2xx, and an explicit "body is read exactly once" assertion.

Mutation-tested both fixes:

• restoring the double-read → "a non-2xx that is NOT a trust-task document keeps the server's error code" fails
• restoring status-first ordering → "a refusal at a non-2xx status still surfaces its machine-readable code" fails

Full suite 204/204 (was 198), clean build and lint.

Not verified: no run against a real VTA emitting a real refusal. The wire shapes come from the existing tests and the trust-task error type, not from observed VTA traffic.

Remaining audit finding

Persist-before-ack (R1.6/R4.1) — @openvtc/vti-didcomm-js acks before dispatching to onMessage, and the wallet persists only the message id, never the body. An offscreen teardown mid-prompt loses a task-consent request permanently. Not fixable in this repo; needs a library change or disabling auto-ack. Worth an issue in the shared repo rather than a patch here.

Pre-merge checklist

• All clients have finite timeouts (R1.2) — unchanged from fix: bound every outbound fetch with a timeout (R1.2) #98
• No lock held across a network await (R1.3) — n/a
• No local state committed before its remote effect (R2.1) — n/a
• Every retry bounded + backed off (R1.4) — the 401 retry is unchanged
• Accept/poll/listen loops survive transient errors (R1.5) — n/a
• Acks/deletes only after durable handoff (R1.6) — untouched; see remaining finding
• New/changed wire types (R3.*) — none; this reads existing shapes correctly
• Config absence = most restrictive (R5.*) — an unparseable body yields a typed error from the status rather than being treated as success
• Logs/status claim only what was verified (R6.*) — this is the fix: errors now report the code the server actually sent
• "Process dies on the next line" answered (R2.1) — no mutation semantics changed
• Deviations flagged with rule numbers — none