fix(http): recover HTTP 421 requests

[JackCaow]

Problem

A pooled connection can become stale or be coalesced to the wrong origin after proxy or network changes. In the observed Moti + Clash Verge incident, Fastly returned HTTP 421 with a TLS SAN mismatch message. Catcher classified every 4xx as non-retryable, and the NAPI wrapper exposed only a generic Error message, so the application could neither recover locally nor reliably inspect error.status.

Changes

• Detect HTTP 421 after the normal request pipeline returns.
• Retire only the current HttpTransport connection pool and retry once on a fresh connection.
• Keep other clients and already in-flight requests untouched.
• Stop after the bounded retry and surface a persistent 421.
• Export HttpError from the NAPI TypeScript wrapper with structured status, body, and cause fields.
• Document the behavior and add Rust plus NAPI regression coverage.

RFC 9110 section 15.5.20 explicitly permits retrying a 421 request over a different connection, even when the method is not idempotent.

Validation

• cargo check --workspace --all-targets
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace
• pnpm build:ts
• pnpm typecheck
• focused NAPI suite: 7 passed
• focused weak-network retry rerun: passed
• git diff --check
• modified Rust file rustfmt check: passed

The full pnpm test run completed 345 passed and 1 skipped, with two unrelated harness failures: the randomized packet-loss assertion (passed when rerun alone) and the optional-agent real-proxy CONNECT test. The latter test server handles regular proxy requests but not CONNECT, and this change does not touch the TypeScript proxy implementation.