All multipart field-construction failures flatten to `MediaFileNotFound`

> Split out from Automattic/wordpress-rs#1497 — *Swift executor URLSession error audit*. Section A — Converted to the wrong Rust 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.** The catch-all at `:618-629` rethrows **every** `MultipartFormField(fileAtPath:)` failure — EACCES, sandbox denial, I/O errors on external volumes — as `MediaFileNotFound(filePath:)`, discarding the underlying error carried by `MultipartFormError.inaccessbileFile`. A file that exists but is unreadable is reported as "not found", sending users looking for the wrong problem. Map only genuine absence (`CocoaError.fileReadNoSuchFile` / `ENOENT`) to `MediaFileNotFound`; surface the rest as `.genericError` with the underlying description. (reqwest is worse here — `Part::file(...).unwrap()` panics — but the Rust side is out of this audit's scope.)

Open native/swift/Sources/wordpress-api/SafeRequestExecutor.swift and inspect the catch-all at lines 618-629 around MultipartFormField(fileAtPath:). Trace how MultipartFormError.inaccessbileFile carries its underlying error, then verify that only CocoaError.fileReadNoSuchFile/ENOENT becomes MediaFileNotFound and other failures surface as .genericError with the underlying description.

Written by the indexing model from the issue text.