`presentedHostnames` carries only the leaf certificate's CN, omitting SANs

[jkmassel]

Split out from #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. handleHttpsError builds presentedHostnames as [siteCertificate.commonName()] even though the parsed SslCertificateInfo exports alternativeNames() over UniFFI. Modern certificates carry their identities in SANs — CN is often empty or unrelated — so the payload can present an empty or misleading name list. reqwest forwards the full presented-names list (presented.to_vec()). One-line fix; LoginTests.swift pins the CN-only shape and needs updating. Relates to #657 (that issue is test coverage; this is the payload), and becomes load-bearing if #1498's host-vs-names comparison lands.

[jkmassel]

Resolved by #1531 (merged 2026-08-12).

The Swift executor no longer builds presentedHostnames from [siteCertificate.commonName()]. handleHttpsError now uses siteCertificate.presentedHostnames() (SafeRequestExecutor.swift:219), and the new presented_hostnames() on SslCertificateInfo (wp_api/src/ssl.rs:105) returns the Common Name (when present) followed by the de-duplicated SANs — so the payload carries the full presented-names set on every executor, and stays correct for SAN-only certificates with no CN. The LoginTests.swift CN-only assertion was de-pinned in the same PR.

Closing as resolved. The classification concern in #1498 and the trust-acceptance concern in #1512 are separate and remain open.