TrustInsights: authorizationStatus returns .unavailable, but requestEvaluation returns .denied — feature missing from Settings (China mainland)

Hi,

I'm integrating the TrustInsights framework (Impersonation Risk Detection, IsLikelyBeingCoachedInsight) announced at WWDC26. I'd like to confirm whether the behavior below is expected regional gating or a misconfiguration on my side.

Environment

• Real device: iPhone 15 , iOS 27.2
• Xcode 27.2 , SDK iOS 27.2
• App has the Trust Insights capability added in Xcode; the embedded provisioning profile includes com.apple.developer.trustinsights.base (verified via security cms -D)
• Deployment target and device OS both satisfy the framework requirements

Code (standard usage)

**Observed behavior**
1. `authorizationStatus(for:)` always returns `.unavailable`.
2. `requestAuthorization(for:)` also returns `.unavailable` — no system permission alert is shown.
3. `requestEvaluation(context:)` throws with the framework log:
4. The Settings entry described in the user-facing docs (Settings → Privacy & Security → Impersonation Risk Detection → "Share with App Developers") **does not exist on this device**, including after search and after a failed evaluation attempt.
5. The documented testing launch argument does reach the process — `UserDefaults.standard.string(forKey: "TrustInsights.IsLikelyBeingCoachedValue")` returns `medium` when launched with `-TrustInsights.IsLikelyBeingCoachedValue medium` — but evaluation still fails with the same `denied`.

**Questions**
1. Is TrustInsights / Impersonation Risk Detection currently unavailable in China mainland (or gated by region/Apple Account storefront)? Is that why `authorizationStatus` returns `.unavailable`?
2. Why do `authorizationStatus` and `requestAuthorization` return `.unavailable` while `requestEvaluation` gets far enough to return `.denied`? Which one reflects the actual gate?
3. If the per-app permission row in Settings is only created after the first `requestAuthorization` flow, how is that supposed to happen when the API returns `.unavailable` without presenting any UI?
4. Is there a supported way to exercise the evaluation pipeline (including the launch-argument overrides) on a device where the Settings entry is absent, so UI/UX work can proceed before regional rollout?
5. Is developer-side enablement required (entitlement request / Feedback) for regions where the feature is not yet live?

Thanks!