Split the media-handler files into one type per file

Follow-up from #621. The media files each hold several types, so the "server" files are doing far too much:

• ios/.../Media/MediaUploadServer.swift — ~795 lines: the server plus the ~275-line InternalMediaClient, UploadError, and UploadContext.
• android/.../gutenberg/MediaUploadServer.kt — ~758 lines: the response model, both protocols, both value types, the server, the exception, and the client.

Proposed split

One concern per file, kept in the same module/package — so no import-path or public-API change, purely organization:

iOS's MediaHandlers.swift dissolves into the first three.

Grouping rationale: each value type sits with the protocol it serves (ProcessedProxyFile → processor, MediaUpload → uploader); MediaUploadResponse gets a neutral home since the client and the server both use it; server-privates stay with the server.

Notes

• Mechanical and low-risk — no logic changes, stays within the existing module/package, so hosts see no API change. Builds + the existing media test suites are the check.
• Keep the media types in the org.wordpress.gutenberg package on Android; a media subpackage would be a public-API break for hosts.

Start with ios/.../Media/MediaUploadServer.swift, ios/.../Media/MediaHandlers.swift, and android/.../gutenberg/MediaUploadServer.kt to identify each listed type and its module or package. Review the existing media test suites before moving declarations. Done means one concern per proposed file, Android types remain in org.wordpress.gutenberg, and builds and media tests still pass without API or logic changes.