The `allowSSL` server-trust override accepts the challenge without evaluating the trust

> Split out from Automattic/wordpress-rs#1497 — *Swift executor URLSession error audit*. Section D — Crash instead of classified error.
>
> File references are to `native/swift/Sources/wordpress-api/SafeRequestExecutor.swift` unless noted; `:NNN` line numbers were verified against `fix/converge-executor-error-classification`.

**Severity: high (security).** The delegate's `didReceive challenge` handler (`:347-363`) returns `(.useCredential, URLCredential(trust:))` as soon as the leaf certificate parses and its CN matches the allowlist — `SecTrustEvaluateWithError` is never called, so chain signature, issuer, and validity dates are never checked. A MITM can self-sign a certificate whose CN copies the legitimate certificate's CN (public information) and be accepted for every host previously passed to `allowSSL(altNames:forCommonName:)`. The comment above the storage states the feature exists to tolerate a hostname missing from an otherwise-valid certificate; the fix is to re-evaluate the trust with hostname checking relaxed but chain validation intact (`SecTrustSetPolicies` with `SecPolicyCreateSSL(true, nil)`, then `SecTrustEvaluateWithError`), falling through to `.performDefaultHandling` on failure. Compounds Automattic/wordpress-rs#1498: apps steered into `allowSSL` by a bogus name-mismatch reason find the exception "works" precisely because validation is fully bypassed.

Start in native/swift/Sources/wordpress-api/SafeRequestExecutor.swift at the didReceive challenge handler around lines 347-363. Trace how allowSSL(altNames:forCommonName:) stores its exception, then review the trust policy and evaluation APIs needed to relax hostname checking without skipping chain validation. Done means matching certificates still require successful trust evaluation and failures fall through to default handling.

Written by the indexing model from the issue text.