fix(ios): own the media upload delegate instead of holding it weakly

[jkmassel]

Stacked on #624. Second of ten PRs splitting #621.

What?

A host that releases its mediaUploadDelegate while an upload is in flight gets the file forwarded to WordPress unprocessed. Hold the delegate strongly, as Android already does.

Why?

The server reads the delegate three times per request — once at the admission gate (handlesFile), then again for processFile and uploadFile. Those reads are separated by a synchronous disk copy and an unbounded processFile. Held weakly, a host releasing its delegate in that window changes the answer between them: a file admitted for processing is delivered untouched.

The weak bought no leak protection to trade away. The cycle it named runs through EditorViewController.mediaUploadDelegate — a host object retaining the view controller forms EditorViewController → delegate → EditorViewController regardless of how the server's container holds it. What it did buy was the reference vanishing mid-request.

How?

• MediaUploadServer.swift: UploadContext holds the delegate strongly and becomes a struct, dropping its @unchecked Sendable opt-out — MediaUploadDelegate is Sendable and DefaultMediaUploader is @unchecked Sendable, so it is implicitly Sendable. Immutable strong references make the three reads agree by construction.
• EditorViewController.swift: mediaUploadDelegate becomes strong. The machinery that existed only to police the old contract goes with it — mediaUploadDelegateWasAssigned and the released-before-load trap have nothing left to catch. Hosts no longer need to retain the delegate themselves.

SwiftLint's weak_delegate is suppressed with the reasoning inline. The rule is arguably right that the name no longer fits; #630 renames the property and the suppression goes away with it.

HTTPServer.stop() now also clears the listener's newConnectionHandler. That block holds the request handler and, through it, the delegate — and cancel() alone does not drop it, so Network.framework performed the final release on its own queue after cancellation completed. A delegate reached through EditorViewController.deinit deallocated off the main thread in 46 of 50 measured runs. Clearing the handler after cancel() makes teardown synchronous on the caller's thread, so retainsDelegateForServerLifetime asserts the release outright instead of polling for it.

Known issue

Owning the delegate means a host whose conformer retains the EditorViewController back forms EditorViewController → mediaUploadDelegate → EditorViewController, and neither is freed. deinit is the only caller of uploadServer.stop(), so a leaked editor also strands its WKWebView and a bound loopback NWListener. Reproduced directly: the same test passes with weak restored and fails without it.

Nothing hits this today — mediaUploadDelegate has no callers in WordPress-iOS, and the demo's Coordinator holds only the view model. But PostGBKEditorViewController already owns its EditorViewController and is its delegate, so the adoption line is one assignment away.

#630 addresses it by dropping : AnyObject from MediaProcessor and MediaUploader, so a host can conform with a value type that captures only what the work needs rather than the view controller. That relaxes the constraint rather than making the cycle impossible, and #630's docs say so.

Testing Instructions

doesNotStronglyRetainDelegate pinned the invariant being removed, so it is replaced by retainsDelegateForServerLifetime, asserting both halves — the server owns the delegate while it runs, and releases it afterward. processesForHostReleasedDelegate covers the bug directly.

• Both fail against a weak container, with the real symptom: passthroughUploadCalled → true
• swift test — host suite green
• iOS Simulator xcodebuild
• SwiftLint clean

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/625")

_{Built from a89459c}