Probe direct host for editor capability detection on Atomic sites

[jkmassel]

Description

Fixes #22879. The editor stalls partway through preloading on WP.com Atomic sites whose direct host doesn't expose wp-block-editor/v1/settings, because capability detection reports "theme styles supported" via the WP.com proxy and then the editor 404s fetching that route from the direct host.

Root cause

EditorSettingsRepository.fetchRouteSupport and GutenbergView were not talking to the same host on Atomic sites:

• Detection: WpApiClientProvider.getWpApiClient(site) returns the WP.com client whenever site.isWPCom || site.isUsingWpComRestApi, so apiRoot() is queried via public-api.wordpress.com. Its route list drives hasRouteForEndpoint("/wp-block-editor/v1", "settings", ...).
• Consumption: GutenbergView uses the configured siteURL (the direct host) for its block-editor settings fetch, not siteApiRoot.

For Atomic sites those two hosts can diverge — the proxy advertises routes the direct host doesn't expose — and we confidently tell the editor "theme styles is supported" right before the editor 404s on the direct host.

Fix

Detect against the host the editor will actually use. For all WP.com Atomic sites, run REST API autodiscovery on site.url and read the routes list off the discovery result directly. Non-Atomic shapes keep the existing getWpApiClient / getApiUrlResolver path.

• WpApiClientProvider: New urlResolverFor(apiRootUrl: ParsedUrl) — a thin wrapper around WpOrgSiteApiUrlResolver so callers can reuse the ParsedUrl returned by discovery without coupling to uniffi internals.
• EditorSettingsRepository: Takes a new WpLoginClient dependency. fetchRouteSupport branches on site.isWPComAtomic: that branch calls wpLoginClient.apiDiscovery(site.url) and uses apiRootUrl + apiDetails from the success result — no second apiRoot().get() needed. Non-Atomic shapes route through fetchRouteSupportViaConfiguredClient, which is the original logic untouched.

Discovery is used rather than an unauthenticated apiRoot().get() against ${site.url}/wp-json so we don't bake in an assumption about where the REST API lives (custom permalink structures or non-default REST API paths would break that).

What we explored

1. Detect against the host the editor will use ✅ — chosen. Specifically, REST API autodiscovery on site.url, so we don't assume the API lives at /wp-json. Matches the project intent of talking directly to the site whenever possible.
2. Probe both, intersect. Would close the false-positive but could close false-negatives we'd want to honor.
3. Have GBKit consume siteApiRoot for wp-block-editor/v1/settings. Library-side change, and the project intent ("direct to the site as much as possible") cuts the other way.

Scope

Covers all WP.com Atomic sites — with or without an application password — because the editor talks to the direct host in both shapes. Atomic + app password didn't reproduce #22879 (Basic auth on the direct host exposes the route anyway), but the symmetric fix avoids surprises later. Non-Atomic shapes (Simple, self-hosted, JPC) keep the existing detection path unchanged.

Testing instructions

Atomic site:

1. Sign into a WP.com account associated with automatticwidgets.wpcomstaging.com.
2. Open My Site for that site and let the dashboard settle so the preloader runs and capability detection completes.
3. Open Site Settings, verify "Use Theme Styles" appears disabled / unsupported.
4. Create a new post., verify the editor opens correctly.
5. Validate that the AI Assistant block is present and insert one. Ask it something, note that it works. This validates that third-party plugins are working correctly.

Simple Site test (regression check):

1. Use a WP.com Simple site, run the same AI Assistant test.

Unit tests:

• ./gradlew :WordPress:testJetpackDebugUnitTest --tests EditorSettingsRepositoryTest — passes (existing tests + new tests covering Atomic direct-host discovery).

[dangermattic]

	1 Warning
⚠️	PR is not assigned to a milestone.

Generated by 🚫 Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress Android by scanning the QR code below to install the corresponding build.

	App Name	WordPress Android
	Build Type	Debug
	Version	pr22883-591dcd1
	Build Number	1488
	Application ID	org.wordpress.android.prealpha
	Commit	591dcd1
	Installation URL	7q787ordnp5vo

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack Android by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Android
	Build Type	Debug
	Version	pr22883-591dcd1
	Build Number	1488
	Application ID	com.jetpack.android.prealpha
	Commit	591dcd1
	Installation URL	4dl9fodsomlv0

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[codecov]

Codecov Report

❌ Patch coverage is 97.05882% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 37.34%. Comparing base (96fc478) to head (591dcd1).

Files with missing lines	Patch %	Lines
...fluxc/network/rest/wpapi/rs/WpApiClientProvider.kt	0.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            trunk   #22883   +/-   ##
=======================================
  Coverage   37.34%   37.34%           
=======================================
  Files        2320     2320           
  Lines      124653   124663   +10     
  Branches    16941    16943    +2     
=======================================
+ Hits        46549    46558    +9     
- Misses      74339    74340    +1     
  Partials     3765     3765           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.