fix(ios): make the Lockdown Mode REST relay serve requests, and contain it

[dcalhoun]

What?

Makes the Lockdown Mode REST relay in #544 actually serve requests, and contains it.

The relay has never served one. upstreamURL(from:) assigned parsed.query to percentEncodedQuery, but query carries its leading ?, so the first query item was named ?url, the lookup for url returned nil, and every request 400d. That masked everything behind it.

Why?

Under iOS Lockdown Mode the editor's file:// page loses its CORS exemption, and WordPress sanitizes Origin: file:// through a protocol allowlist that excludes file — so it answers with an empty Access-Control-Allow-Origin and WebKit rejects every response. The relay is the way REST works at all in that mode.

Behind the 400, several defects would have surfaced in order. The three worth calling out by user impact:

• Every save silently lost its content. proxyFetch read options.body, but api-fetch serializes options.data into a JSON body inside defaultFetchHandler, which the relay short-circuited past. Writes went out with Content-Length: 0; WordPress answered 200 with the record unchanged, and the editor reported success.
• The editor reported that the user could do nothing. canUser issues OPTIONS and reads the Allow response header. A relayed OPTIONS and a browser preflight arrive at the same target, so the permissive CORS layer answered both with 204 and the handler never ran — and Allow wasn't in Access-Control-Expose-Headers anyway. No error surfaced, because the request "succeeded".
• A relay failure reached JavaScript unreadable. Error bodies were text/plain, so they arrived as invalid_json with the real reason lost.

Two security gaps: the SSRF guard matched a caller-supplied absolute URL by string prefix without normalizing .. segments, and URLSession followed 3xx responses with no task delegate, so the check only ever applied to the first hop.

How?

The relay takes a path, not a URL. The upstream path rides in the request path — /proxy/wp/v2/posts?_locale=user — and resolves natively against the configured site API root. There is no caller-supplied URL to contain, dot segments are refused outright, and each request identifies itself in a network log. Resolution appends to the root rather than resolving against it, mirroring createRootURLMiddleware, because a site on plain permalinks has https://example.com/?rest_route=/ where the path has to merge into an existing query.

The relay is the transport, not a middleware. apiFetch.use() unshifts and api-fetch composes with reduceRight, so a registered middleware can never run innermost — it short-circuits past data-to-body serialization, the default Accept header, the HTTP v1 method override, signal, and every response-parsing rule. Wrapping fetch puts the relay below all of it: api-fetch builds the whole request and parses whatever comes back, and this layer only changes where the request goes. Which transport to use is read from configuration rather than inferred from an observed success, so one misleading response can no longer latch the editor onto the wrong path for a session.

Preflights and deliberate OPTIONS are told apart by Access-Control-Request-Method, in the HTTP server and in the wp-env CORS shim, which had the same bug. Allow is exposed in both.

Site URLs are recognized across host aliases. WordPress builds Link headers from home_url(), which need not be the configured host — wp-env is the everyday case, and e2e/wp-env-fixtures.js already documents the same divergence. Path differences stay unmatched deliberately: in a subdirectory multisite two roots differing only by path are separate sites.

Also: redirects out of the API root are refused and answered rather than relayed (relaying the 3xx let fetch follow it, undoing the refusal); the connection limit is raised off the library default of 5, which editor boot exceeds; and the demo app's compiled-in wp-env credentials and the dead origin probe are gone.

Sixteen numbered items, one per commit where they were separable. The commit messages carry the detail.

Testing Instructions

Automated coverage first — none of it needs a site except where noted:

make test-js                                    # 263 tests
swift test                                      # 984 tests
make wp-env-start                               # then, against a live site:
WP_ENV_CREDENTIALS_PATH="$PWD/.wp-env.credentials.json" swift test --filter RestRelayIntegrationTests

The last one relays real requests against wp-env: a write is read back to confirm the record actually changed, Allow is asserted end to end, and ten concurrent requests are fired (which fails at the old connection cap).

Manual testing is in the review comments — the regression risk is in paths the suites can't reach, and it needs a device or simulator.

[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/610")

_{Built from c2ebc04}

[dcalhoun]

Superseded by #611.