On Linux, the SSL predicate never fires — all certificate failures become `GenericError`

> Split out from Automattic/wordpress-rs#1497 — *Swift executor URLSession error audit*. Section C — SSL payload and platform gaps.
>
> 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.** Verified against swift-corelibs-foundation `swift-6.2.1-RELEASE`: the libcurl bridge (`MultiHandle.swift`, `urlErrorCode(for:)`) maps no curl SSL error to any `NSURLError` SSL code — `CURLE_PEER_FAILED_VERIFICATION`, `CURLE_SSL_CONNECT_ERROR`, expired/self-signed/wrong-name certs all fall to `NSURLErrorUnknown`. So `errorIsHttpsError` never matches on Linux and the Linux accommodation in `getPeerCertificateChain` (return `[]`, `:296-297`) is dead code. Similarly `.notConnectedToInternet` is never produced there. At minimum, the platform-differences rustdoc (which covers Kotlin/reqwest/Darwin but says nothing about Linux SSL) should document the degradation; the durable fix is an upstream corelibs mapping. Steering Linux consumers to the reqwest executor is the pragmatic alternative.

Start with native/swift/Sources/wordpress-api/SafeRequestExecutor.swift, especially errorIsHttpsError and getPeerCertificateChain at :296-297, then inspect the platform-differences rustdoc. Confirm the Linux behavior against swift-corelibs-foundation's MultiHandle.swift and urlErrorCode(for:). Done means documenting the SSL and connectivity degradation, or clearly isolating the required upstream corelibs mapping and Linux guidance.

Written by the indexing model from the issue text.