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.

Beginne im aktuellen RN-Pfad für die Divergenz zwischen test-app und production und suche collectSettleChromeRefs, collectKeyboardAccessoryIndexes und SCREEN_REF_CAPTURE_LIMIT. Füge Fixtures für einen kurzen Bildschirm mit fokussiertem Input, ein natives UIKit inputAccessoryView und einen Dialog für Laufzeitberechtigungen hinzu, und zwar mit den im Issue genannten Ansätzen. Erledigt ist die Aufgabe, wenn Live-Divergenz-Captures die Guards gegen Überfilterung ausführen, während die bestehende Unit-Test-Abdeckung intakt bleibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.