Duplicate fetchEditorCapabilitiesForSite call between GutenbergEditorPreloader and SiteConnectivityBannerViewModelSlice

Background

Two callers independently invoke EditorSettingsRepository.fetchEditorCapabilitiesForSite(site) during MySiteViewModel.refresh() and onResume():

• GutenbergEditorPreloader.preloadIfNeeded / refreshPreloading — added in #22579.
• SiteConnectivityBannerViewModelSlice.fetchCapabilities — added in #22834.

Both fire on every refresh and resume, so on a cold launch both callers race the same fetch.

EditorSettingsRepository.fetchEditorCapabilitiesForSite has no in-flight deduplication — each call fans out two async requests (fetchRouteSupport, fetchThemeBlockStyleSupport) and they all write back to the same appPrefsWrapper keys. So a first-launch refresh issues 4 parallel HTTP requests when one would do, with last-write-wins races on shared prefs.

Mitigating factors

• Both callers have per-session dedup after a successful fetch (shouldPreload state map in the preloader; fetchedCapabilitiesForSite set in the slice), so the duplicate only happens on the first call per site per session.
• The shared-prefs race is usually benign — both writers write the same value — but it's wasted bandwidth and a small thundering-herd on the WP API for the apiRoot fetch.

Possible fixes

1. In-flight dedup at the EditorSettingsRepository layer (e.g. a per-site Deferred cache that the second caller awaits).
2. Have the connectivity slice observe the preloader's result (the preloader is the de-facto driver of editor capabilities; the slice's banner is downstream of whether that fetch succeeded).
3. Inverse: have the preloader observe the slice (less natural — the slice exists to react to the fetch, not own it).

Option 2 is the cleanest if the preloader's fetch path can expose a success/failure signal the slice can subscribe to.

Related

• #22579 (introduced GutenbergEditorPreloader)
• #22834 (introduced the connectivity-banner slice)

Start by reading EditorSettingsRepository.fetchEditorCapabilitiesForSite and the callers GutenbergEditorPreloader.preloadIfNeeded/refreshPreloading and SiteConnectivityBannerViewModelSlice.fetchCapabilities. Compare their per-session state and determine whether repository-level in-flight deduplication or sharing the preloader result best fits the existing flow. Done means a cold-launch refresh performs one capabilities fetch, with the connectivity banner still receiving the fetch's success or failure.