`execute()` on an owner-invalidated injected session crashes with an uncatchable NSException

> 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: low.** After the session owner calls `invalidateAndCancel`, the next `execute()`/`upload()` calls `session.dataTask`/`uploadTask` on the invalidated session, which raises Foundation's "task created in a session that has been invalidated" NSException — uncatchable from Swift. Requires caller misuse; worth a doc note that the injected `URLSession` must outlive the executor (or track `didBecomeInvalidWithError` and fail fast with `GenericError`). Incidentally, this lens confirmed the `.cancelled → CancellationError` mapping is honest: the library's own two cancel paths and an in-flight `invalidateAndCancel` all funnel there, and the challenge handler never returns `.cancelAuthenticationChallenge`, so no non-cancellation source of `.cancelled` exists in this executor. ✅

Start with native/swift/Sources/wordpress-api/SafeRequestExecutor.swift and trace the execute/upload path after an injected URLSession is invalidated. Done means the injected-session lifetime requirement is documented, or invalidation is tracked so the call returns GenericError instead of raising the uncatchable NSException.

Written by the indexing model from the issue text.