Test-fixture gaps for divergence chrome-filter over-filtering live evidence (short-form screen, native inputAccessoryView, runtime-permission action)

## Summary

Follow-up from the #1233 reviews (merged). The divergence chrome-filter **over-filtering** live-evidence requirement (does the filter wrongly *drop* legit app/actionable controls?) could not be produced end-to-end with the current RN test-app, because the fixtures don't create the states the exemptions target. These are test-fixture gaps, not product bugs — capturing them so the over-filtering guards can be validated on the production divergence route rather than unit-only.

## Fixture gaps

**1. Short-content screen with a focused input + app control (iOS "accessory survives *within 20 refs*").**
The accessory buttons survive `collectSettleChromeRefs` (verified on a real device tree), but the `field-accessory-input` lives at the bottom of the dense Checkout form, so in a live `get`/`is`/`wait` divergence the app controls ahead of it fill the `SCREEN_REF_CAPTURE_LIMIT` (20) and the accessory is truncated by the cap, not by filtering. A minimal screen (one focused field + a couple of app-owned controls, well under 20 interactive nodes) would let a divergence payload actually show the app-owned control retained within 20 with the keyboard up.

**2. Native-UIKit `inputAccessoryView` hosted inside the keyboard window (iOS geometric exemption).**
RN's `` renders in a **separate window** from `UIRemoteKeyboardWindow`, so the whole-window keyboard classifier never sweeps it — meaning the geometric exemption `collectKeyboardAccessoryIndexes` (the actual over-filter guard, which keeps a control whose center sits above the keyboard container's top edge *inside the keyboard window*) is never exercised by any RN fixture. A native accessory-view fixture (a small UIKit host, or an Expo config-plugin/native module that sets a real `inputAccessoryView` on a `UITextField`) is required to exercise that exemption live. It stays unit-covered otherwise.

**3. A runtime-permission action (Android permission dialog surviving the filter).**
The test-app declares no dangerous runtime permission, so there is no permission dialog to raise. A screen that requests one (e.g. camera/mic via `expo-camera`/`expo-av`) would let a divergence capture a `com.google.android.permissioncontroller` dialog surviving the Android settle-chrome filter (foreign-package dialogs are kept by design). Note the *actionable-`com.android.systemui`* survival case is separately blocked by #1251 (systemui classification is inert in the non-raw divergence capture until that lands).

## Why it matters

With these fixtures, the over-filtering live cases the #1233 reviews asked for become producible on the real divergence route, closing the gap between "unit-covered + reasoned structurally absent for RN" and "device-facing evidence". Lower priority than #1251 (which is a real product bug); this is test-infrastructure.

Start in the current RN test-app and production divergence route, locating collectSettleChromeRefs, collectKeyboardAccessoryIndexes, and SCREEN_REF_CAPTURE_LIMIT. Add fixtures for a short focused-input screen, a native UIKit inputAccessoryView, and a runtime-permission dialog using the approaches named in the issue. Done means live divergence captures exercise the over-filtering guards, while the existing unit coverage remains intact.

Written by the indexing model from the issue text.