Live Caller ID Lookup: privacy proxy not provisioned for production bundle id, 17 days after Identity & Trust configuration approval

Live Caller ID Lookup works with development-signed (Xcode) builds but fails on the App Store build of the same app. On production devices every authenticated request (`/token-key-for-user-token`, `/issue`) fails on-device in ~47 ms, before any traffic leaves the device. The unauthenticated issuer directory fetch succeeds, so server-side we only ever see directory requests and nothing else.

Device log:

```
nw_endpoint_proxy_handler_should_use_proxy: "Proxies not present, but required to fail closed"

ciphermld(CipherML) : queryStatus(for:options:) threw an error:
Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline."
NSErrorFailingURLKey=https:///token-key-for-user-token
_NSURLErrorPrivacyProxyFailureKey=true
NSUnderlyingError={NSPOSIXErrorDomain Code=50 "Network is down"}
(_NSURLErrorNWPathKey=satisfied, Wi-Fi up, LQM: good)
```

Reproduced on two networks and after a device restart. The ~47 ms failure is below network RTT, so the request is refused locally: no privacy proxy configuration is present for the extension and the connection fails closed. This matches what DTS described in developer forums thread 821619 for NEURLFilter (development builds bypass the proxy; production builds require provisioning).

Our Identity & Trust configuration has shown "Approved" in CloudKit Console for over two weeks. The deployment passes every documented onboarding check: HTTP/2 ALPN on all hosts, the validation Bearer token returns 200 on `/token-key-for-user-token`, the OHTTP gateway serves a valid key config (X25519 / HKDF-SHA256 / AES-128-GCM), DNS TXT record set, test identity present. Device: iOS 26.6.1.

Questions:
1. Is relay/privacy-proxy provisioning for the production bundle id a separate step after console approval, and what is the expected propagation time?
2. Is there any way to check provisioning status?
3. If two identical configurations were accidentally submitted and both show "Approved", can the duplicate block provisioning, and should one be revoked?

Start with the production-device logs and the CloudKit Console Identity & Trust approval state; compare the App Store bundle behavior with the development-signed build and the documented NEURLFilter requirements. Done means establishing whether provisioning is separate, how its status and propagation are checked, and whether duplicate approved configurations require revocation.

Written by the indexing model from the issue text.