`.appTransportSecurityRequiresSecureConnection` has no classification

> Split out from Automattic/wordpress-rs#1497 — *Swift executor URLSession error audit*. Section B — Unchecked URLError codes we could classify better.
>
> 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: medium.** An http:// site blocked by ATS fails before any connection is attempted and lands in `GenericError`. No existing variant fits: `NonExistentSiteError` is wrong (the site exists), `InvalidSslError` is wrong (no certificate was presented — the variant is documented as present-but-untrusted), and it is not offline. This wants a new variant (e.g. `InsecureConnectionNotAllowed { hostname }`) so apps can show the actionable "this site doesn't support HTTPS" guidance that Automattic/wordpress-rs#1192 asks for — this finding is the Swift-executor-side enabler for that issue. Apps setting `NSAllowsArbitraryLoads` never hit the code, which caps the severity.

Start with native/swift/Sources/wordpress-api/SafeRequestExecutor.swift and the referenced lines on the fix/converge-executor-error-classification branch. Trace how the ATS-related URLError reaches GenericError, then define the classification needed for an actionable HTTPS message while preserving existing NonExistentSiteError, InvalidSslError, and offline distinctions.

Written by the indexing model from the issue text.