Fix sign-in waiting on a background-priority callback

[jkmassel]

Fixes sign-in staying on the login screen for seconds longer than it needs to, and for as long as the device is busy with anything else, because the last thing it waits for was handed back on the background queue.

Stacked on #26116 so that #26119 can sit on top of both. The two fixes don't depend on each other.

Root cause

Signing in fetches the account's sites, then each site's Jetpack capabilities, and isn't finished until the capabilities arrive: BlogService.syncBlogsForAccount → JetpackCapabilitiesService.sync → JetpackCapabilitiesServiceRemote.for(siteIds:). That last method gathers the responses with a DispatchGroup and called back with notify(queue: .global(qos: .background)).

The system serves the background queue last. While anything else wants the CPU it can leave that work unstarted, and even on an idle device the hop costs seconds. A sample of the app while it sat on the login screen showed the main thread idle and two dispatch worker threads that had been created and hadn't run an instruction.

The same callback also gates every later refresh of the account's sites, and of one site's details (BlogService.blogDetailsHandler).

Fix

Call back on the default-priority global queue.

Measurements

Time from launch to My Site's first request, signing in with a token on an iPhone 18 Pro simulator (iOS 27.0) with every response served locally, so that nothing but the app is being timed. Measured on #26119's branch, which has the token sign-in and the HTTP fixtures this needs.

	Before	After
Idle Mac	6.4 s, 7.1 s	3.3 s, 3.3 s
Every core busy (32 × yes > /dev/null)	not within 120 s	3.5 s, 3.3 s, 3.2 s

In both "before" rows the sites and their capabilities had all been answered about 3 seconds after launch. The rest was the wait for the callback.

This is what failed the first UI test in 5 of 10 CI jobs on #26119: the Simulator had only just booted and was still busy, and the app was on the login screen 76 seconds after launch with every request answered.

Test plan

• The new testCapabilitiesAreNotDeliveredAtBackgroundPriority fails without the fix, with XCTAssertNotEqual failed: ("qos_class_t(rawValue: 9)") is equal to ("qos_class_t(rawValue: 9)"), where 9 is QOS_CLASS_BACKGROUND. With the fix it passes, along with the other two tests in JetpackCapabilitiesServiceRemoteTests.
• The measurements above.
• Sign out, then sign in to WordPress.com: the app goes to My Site with the account's sites listed.
• Pull to refresh the site list in the site picker: it finishes and the sites are still listed.

[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 Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Configuration	Release-Alpha
	Build Number	34853
	Version	PR #26121
	Bundle ID	com.jetpack.alpha
	Commit	f02c27a
	Installation URL	5umv7bpdgot40

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 WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Configuration	Release-Alpha
	Build Number	34853
	Version	PR #26121
	Bundle ID	org.wordpress.alpha
	Commit	f02c27a
	Installation URL	1dm2fvep0thkg

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