fix(ai): remove over-safe provider error handling - #42610

Summary

This removes the native request executor's vibed, over-safe provider-error policy and aligns it with pre-existing legacy behavior such as the AI SDK path.

Specifically, this kills:

• the 500-character gate that discarded valid structured provider messages
• the 16 KiB response-body cap and bodyTruncated behavior
• structural response-body redaction based on names such as token, secret, key, and authorization
• literal replacement of request header and query values echoed by providers
• automatic masking of request URL query parameters
• automatic and CurrentRedactedNames-driven request/response header redaction at the executor seam
• raw-body display for short unrecognized payloads

Structured error.message and top-level message values are now parsed from the complete response and surfaced regardless of size. Complete response bodies, URLs, headers, and transport messages are retained in HTTP diagnostics. Unrecognized or malformed payloads use the generic HTTP status fallback rather than being printed as the user-facing message.

Why

The removed behavior was vibed, "over-safe", and inconsistent with pre-existing legacy behavior from integrations such as the AI SDK. It silently threw away useful provider errors based on arbitrary body-length thresholds and applied a separate sanitization policy only to the native path. Matching the established behavior makes native and legacy provider failures predictable and preserves the actual diagnostic evidence.

Checks

• bun test test/executor.test.ts --timeout 30000 --test-name-pattern 'RequestExecutor'
• bun test test/provider/openai-chat.test.ts test/provider/openai-responses.test.ts test/provider/anthropic-messages.test.ts --timeout 30000 --test-name-pattern 'fails HTTP provider errors before stream parsing'
• bun typecheck

Requested by: @rekram1-node (Aiden Cline via Slack)