Decide whether wordpress-rs clients should receive the app's OkHttp interceptors

Three of the five places we construct a wordpress-rs client drop the app's OkHttp interceptors. The code change is small; the open question is whether we want it.

Where we stand

The library supplies no interceptors of its own — DefaultHttpClient.buildClient() adds only the caller-supplied list, a hostname verifier, and timeouts. So whatever we do not pass, nothing supplies.

Two interceptors exist. TrackNetworkRequestsInterceptor (production) wraps Chucker and is a pass-through unless the network-troubleshooting preference is on. MockingInterceptor (androidTest only) redirects WordPress.com hosts to a local mock server.

What it costs today

• Requests through those three paths never appear in the in-app network log: the posts/pages service layer, WordPress.com wordpress-rs traffic, and the domains screen. Developer-facing only, and only when the preference is enabled — but it is the tool you would reach for while debugging exactly those screens, and it shows nothing rather than failing.
• Instrumented tests cannot mock WordPress.com wordpress-rs traffic. Whether any current test needs to is unverified.

How it arose

WpComApiClientProvider was added 2025-10-22, before the Chucker integration landed 2025-12-04 (2ae0e030aed), so it predates the pattern. WpServiceProvider came later and did not pick it up. This looks like drift rather than a decision, which is why it is worth making one.

If we decide to do it

Inject @Named(OkHttpClientQualifiers.INTERCEPTORS) into WpServiceProvider and WpComApiClientProvider the way WpApiClientProvider already does, and change getWpComApiClient from emptyList() to interceptors.toList().