fix: resolve the REST index locally on namespaced sites

[dcalhoun]

What?

Resolve Gutenberg's REST API index request locally on namespaced sites instead of sending it to the API host's root.

Why?

This was primarily implemented to address an observed request failure in the console. There was no user-facing issue observed.

The editor fails a request on every launch for a namespaced site. Gutenberg's root/__unstableBase entity fetches the REST API index (/?_fields=...) during initialization. That path has no segments for apiPathModifierMiddleware to insert the namespace into, so the request targets the bare API host root, which serves no index. Over HTTP origins (the Vite dev server, Android) it fails CORS preflight; from file:// on iOS it follows a redirect to a docs page and fails JSON parsing.

The only unconditional consumer, useBlockEditorSettings, reads image sizes for client-side media processing, which GutenbergKit does not enable. The Site Title, Tagline, and Logo blocks read the site entity when the user can edit settings and only fall back to this record otherwise. No namespaced route serves the index, so there is nothing to redirect to.

How?

Add siteIndexMiddleware to configureApiFetch. For GET requests to / on a site with a configured API namespace, it resolves with home and url from the host's siteURL rather than calling next. Every other request passes through unchanged. It runs after the preloading middleware so a host-supplied index entry still takes precedence.

Testing Instructions

Tip

Use the bundled build rather than the Vite dev server for step 4. Some hosts answer the index request from a dev-server origin with a 429 that carries no CORS headers, which the browser reports as a CORS failure unrelated to this change.

1. Run make build and launch the demo app against a namespaced site (e.g., WordPress.com Simple).
2. Open Web Inspector's Network tab, filtered to XHR/Fetch.
3. Confirm no request to the API host root (/?_fields=...) appears and the editor loads normally.
4. Repeat against a self-hosted site and confirm the index request still goes to <siteApiRoot>/?_fields=... and succeeds.
5. npm run test:unit -- src/utils/api-fetch.test.js

Example root /?_fields=... request:

Accessibility Testing Instructions

No UI changes.

🤖 Generated with Claude Code

https://claude.ai/code/session_017jPW5y3FrRywuHHn3gAHgu

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

_{Built from ef26163}

[adalpari]

Looks good, but Claude found these could of points that might be worth a look:

1. url is set equal to home — wrong when WordPress lives in a subdirectory (api-fetch.js:493)
   The synthesized REST index sets url (WordPress address / siteurl) equal to home (site address). On installs where they differ — e.g. WordPress files at https://example.com/wp but home at https://example.com/ — any consumer that reads the root entity’s url field (to derive the REST/admin base) gets the wrong path.

2. Trailing-slash normalization duplicated from ajax.js (api-fetch.js:492)
   ajax.js:24 already does rawSiteURL?.replace（//+$/, ''） and this line repeats it verbatim. The normalization rule (and the GBKit key it reads) now lives in two places and can silently diverge. A shared normalizedSiteURL() helper in bridge.js would centralize it.