WpApiClient.applicationPasswords().createForCurrentUser fails with rest_no_route on Atomic (WP.com proxy)

## Summary

`WpApiClient.applicationPasswords().createForCurrentUser` returns `WpError(404 rest_no_route)` when run against an Atomic site routed through the WP.com proxy. The proxy doesn't expose this endpoint at `/wp/v2/sites/{site_id}/users/me/application-passwords`, so any client built with `WpComDotOrgApiUrlResolver` can't mint application passwords on Atomic.

## Repro

Build a `WpApiClient` for an Atomic site the way the SDK already supports for proxied WP.com calls:

```kotlin
val client = WpApiClient(
apiUrlResolver = WpComDotOrgApiUrlResolver(siteId = "", baseUrl = WpComBaseUrl.Production),
authProvider = WpAuthenticationProvider.dynamic(/* WP.com bearer token */),
requestExecutor = WpRequestExecutor(/* ... */),
appNotifier = /* ... */
)
val response = client.request {
it.applicationPasswords().createForCurrentUser(
ApplicationPasswordCreateParams(appId = null, name = "Test")
)
}
```

Tested against an Atomic site (`*.wpcomstaging.com`) with a valid WP.com bearer token.

## Result

```
WpError(
errorCode = WpErrorCode.CustomException(v1=rest_no_route),
statusCode = 404,
response = {"code":"rest_no_route","message":"No route was found matching the URL and request method.","data":{"status":404}},
requestUrl = https://public-api.wordpress.com/wp/v2/sites//users/me/application-passwords,
requestMethod = POST
)
```

GET / list / delete on the same endpoint were not tested in this repro, but the underlying issue is the same: the WP.com REST proxy doesn't surface `application-passwords` routes.

## Why it matters

Atomic sites are full WordPress installs and *do* support application passwords on their direct host. The mobile apps need to create application passwords on the user's behalf so they can authenticate REST calls on Atomic without bouncing the user through `authorize-application.php` in a Chrome Custom Tab.

Today the WordPress / Jetpack Android apps do this via the legacy FluxC stack, which uses the Jetpack tunnel — `https://public-api.wordpress.com/jetpack-blogs/{site_id}/rest-api/?path=/wp/v2/users/me/application-passwords/` — which *does* forward this endpoint. That's the only working WP.com-side path I'm aware of for Atomic.

## What would help

Either of:

1. The WP.com REST proxy adds the `application-passwords` routes under `/wp/v2/sites/{site_id}/...` so the existing `WpComDotOrgApiUrlResolver` Just Works.
2. wordpress-rs grows a Jetpack-tunnel URL resolver (or equivalent) that constructs the `/jetpack-blogs/{id}/rest-api/?path=...` URL shape, so SDK consumers have a wordpress-rs-native way to reach endpoints the proxy doesn't surface.

(1) is cleaner from an SDK perspective; (2) is more general and unblocks other tunnel-only endpoints too. Either would let us drop the FluxC mint path on Android.

## Related

- WordPress-Android PR https://github.com/wordpress-mobile/WordPress-Android/pull/22885 — confirmed the failure mode while wiring up headless app-password creation on Atomic; falls back to the FluxC Jetpack-tunnel client for now.

Start at WpApiClient, applicationPasswords().createForCurrentUser, and WpComDotOrgApiUrlResolver to trace how the Atomic request becomes the WP.com proxy URL. Compare that path with the Jetpack-tunnel URL described in the issue and determine whether the proxy or a new resolver is the intended scope; done means Atomic application-password creation works through a wordpress-rs-native path.

Written by the indexing model from the issue text.