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 without an application password:

• 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 without an application password those two hosts 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 WP.com Atomic without an application password, probe apiRoot() on the direct host (${site.url}/wp-json) with an unauthenticated WpApiClient rather than the WP.com proxy. All other site shapes keep the existing getWpApiClient / getApiUrlResolver path.

• WpApiClientProvider: New getDirectHostUrlResolver(site) and createUnauthenticatedDirectHostClient(site). The new client uses WpAuthentication.None and always points at ${site.url}/wp-json, even if wpApiRestUrl is set elsewhere. Not cached — these are one-off probe clients.
• EditorSettingsRepository.fetchRouteSupport: Selection logic moved into probeClientAndResolver(site). For site.isWPComAtomic && !site.hasApplicationPassword(), returns the direct-host pair; otherwise unchanged.

What we explored

1. Detect against the host the editor will use ✅ — chosen. 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

Strictly scoped to the WP.com-Atomic-without-app-password shape per #22879. Atomic + app password still routes through the WP.com client for detection even though the editor uses the direct host (with the app password) — that's a potential follow-up if it surfaces, but the original report didn't reproduce on that shape.

Testing instructions

Atomic site without an application password — direct host missing wp-block-editor/v1/settings:

1. Sign into a WP.com Atomic site whose direct host doesn't expose wp-block-editor/v1/settings (a wpcomstaging.com Storefront-themed site works — e.g. 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 and preloads dependencies without stalling at ~81/100.

Atomic site with an application password (regression check):

1. Sign into an Atomic site with an app password configured.
2. Open Site Settings.

• Verify "Use Theme Styles" reflects what the WP.com proxy reports (unchanged behaviour from before this PR).

Non-Atomic / Simple / self-hosted (regression check):

1. Use a WP.com Simple site or a self-hosted site.

• Verify capability detection still goes through the existing client and the editor opens normally.

Unit tests:

• ./gradlew :WordPress:testJetpackDebugUnitTest --tests EditorSettingsRepositoryTest — passes (existing tests + 2 new tests covering the Atomic-no-app and Atomic-with-app-password paths).

[dangermattic]

	1 Message
📖	This PR is still a Draft: some checks will be skipped.

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-41f8a18
	Build Number	1488
	Application ID	org.wordpress.android.prealpha
	Commit	41f8a18
	Installation URL	1dn2s28qnkpog

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-41f8a18
	Build Number	1488
	Application ID	com.jetpack.android.prealpha
	Commit	41f8a18
	Installation URL	10tt05spe8jf8

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 31.81818% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 37.31%. Comparing base (d0a7db5) to head (41f8a18).

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

Additional details and impacted files

@@            Coverage Diff             @@
##            trunk   #22883      +/-   ##
==========================================
- Coverage   37.31%   37.31%   -0.01%     
==========================================
  Files        2319     2319              
  Lines      124559   124576      +17     
  Branches    16921    16922       +1     
==========================================
+ Hits        46484    46487       +3     
- Misses      74319    74333      +14     
  Partials     3756     3756              

☔ 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.