`buildURLRequest` force-unwraps `URL(string:)`, crashing where the documented `badURL → NonExistentSiteError` path should fire

> 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.** `let url = URL(string: self.url())!` (`:530`). The package supports iOS 16 / macOS 13, where Foundation's strict parser returns `nil` for characters the Rust `url` crate legally leaves unencoded in paths and queries (`|`, `^`, `[`, `]`; query also `{`, `}`). A user-typed site URL like `https://example.com/blog|dev/` parses through `ParsedUrl`, reaches the executor as a valid `WpEndpointUrl`, and the force-unwrap traps — a hard crash from user input. Throwing `URLError(.badURL)` instead routes it through the existing dispatch to `NonExistentSiteError` with no new plumbing. Unreachable on iOS 17+/macOS 14+ (lenient parser); the in-file rationale at `:249-257` only reasons about modern Foundation, which doesn't hold on the declared minimums.

Start in native/swift/Sources/wordpress-api/SafeRequestExecutor.swift at the URL construction around line 530, then read the existing error dispatch and the rationale around lines 249-257. Confirm that malformed Foundation URLs follow the documented NonExistentSiteError path without trapping; completion should preserve the declared iOS 16 and macOS 13 behavior.

Written by the indexing model from the issue text.