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 <InputAccessoryView> 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.

Bắt đầu từ tuyến đường phân kỳ hiện tại giữa test-app và production của RN, xác định collectSettleChromeRefs, collectKeyboardAccessoryIndexes và SCREEN_REF_CAPTURE_LIMIT. Thêm fixtures cho một màn hình ngắn có input đang được focus, một inputAccessoryView native của UIKit và một hộp thoại cấp quyền runtime, bằng các cách tiếp cận được nêu trong issue. Hoàn thành khi các bản capture phân kỳ trực tiếp kích hoạt các guard chống lọc quá mức, trong khi độ bao phủ unit test hiện có vẫn nguyên vẹn.