fix(core): redact sensitive fields when a response fails to parse

[mattespapier]

In strict mode, when a 2xx response doesn't match the spec, <Sdk>ParseError.body carries the whole body, including fields the spec marks sensitive, and in the default lenient mode a body that isn't JSON comes back as the success value. Here is Polar's webhooksGetWebhookEndpoint (its secret is sensitive), a real call to the Polar sandbox through the real SDK, with the reply cut off mid-secret by a fetch wrapper on our side:

// 200 {"created_at":"…",…,"id":"5a61…",…,"secret":"<first half of the secret>
webhooksGetWebhookEndpoint({ id });

 {
-  _tag: 'Success',
-  value: '{"created_at":"2026-10-09T15:46:04.941999Z",…,"secret":"<first half of the secret>'
+  _tag: 'Failure',
+  failure: {
+    _tag: 'PolarParseError',
+    body: '[REDACTED]',
+    cause: 'Invalid JSON response'
+  }
 }

wrapSensitive only runs on the success value; the error carried the body as read, and a mismatched body may hold the secret at an unmodeled key, so the whole body is withheld.

• For outputs where hasSensitiveMember(ast), makeRestProtocol's parse errors report body: "[REDACTED]"; others are unchanged.
• For those outputs, lenient mode now fails a non-JSON 2xx body instead of returning the text.
• hasSensitiveMember looks inside map values and list elements, so a secret inside a map (Meilisearch getembedders, *.apiKey) or a marked list element counts. No generated output marks a list element yet.
• Stripe's protocol and Fly.io's GraphQL and Sprites decoders, which wire validateResponse themselves, do the same; Fly's Sprites token mint always reports "[REDACTED]".

Each case below is a real call through the real SDK, with the reply changed on our side before the SDK reads it: cut off in the middle of the secret, or with one field given the wrong type. On main:

• cut off, default (lenient) mode: the call succeeds and returns the cut-off text, secret included;
• cut off, strict mode: the call fails and the error's body holds that text;
• wrong type, strict mode: the call fails and the error's body holds the whole secret, which prints when the error is logged or serialized.

On this branch the secret appears in none of them. A wrong type in lenient mode is unchanged (see "Not covered"). Tested on:

• Polar (sandbox): webhooksGetWebhookEndpoint, secret, on an endpoint created for the run and deleted after.
• Neon: getProjectBranchRolePassword, password.
• Stripe (test mode): CreateWebhookEndpoint, secret (returned only at creation), each endpoint deleted after.
• Fly.io: GraphQL addOn on a Fly Redis add-on, password, read once and replayed (the GraphQL decoder); one Sprites token minted by listSprites, its mint reply replayed through listSprites (the token mint) and createOrganizationToken (the Sprites decoder), token.

Not covered: the other protocols that wire validateResponse themselves (Azure, Coinbase, MongoDB Atlas, Slack, STACKIT, Supabase and ZeroSSL), AWS's own client, error responses (an HTTP error status, or a GraphQL errors reply), and debug HTTP logging. In lenient mode a sensitive member that arrives with the wrong type (Neon's password as ["…"]) is still returned as read, unwrapped, since wrapSensitive wraps strings only. On success, a secret under a map value or in a marked list element is still returned as read, since wrapSensitive wraps object members only. Fly's GraphQL decoder doesn't call wrapSensitive on success, so a successful addOn returns password and publicUrl as plain strings, on main and here. Out of scope: the distilled-sdk skill still says lenient mode returns a non-JSON body as text.

On main, 13 of the 14 new cases fail (6 of 7 in core, both in Stripe, all 5 in Fly.io); the 14th checks a matching body still succeeds with the member redacted.

Checked: pnpm vitest run on core, Stripe and Fly.io (792 pass; 778 on main), the tests of the other seven packages above plus ACME, Polar, Neon, trigger.dev and Cloudflare (242 pass), format:check, lint, tsc -b --noCheck false on the whole repository (0 errors).

Related: #754's new parseError call in protocol-rest.ts should use hasSensitiveMember.