fix(android-navigation): restore hidden-tab bottom touches

[AtomsH4]

Summary

• patch react-native-bottom-tabs@1.4.0 on Android so hidden tab scenes report the layoutHolder size after layout
• exclude the hidden Material bottom navigation subtree from React Native touch-target traversal while preserving normal tab interaction when visible
• add an installed-source patch guard and document the root cause and device evidence

Root cause

On Android, hiding the native Material bottom bar sets it to GONE, but the view and its tab items retain their previous bounds. React Native's TouchTargetHelper traverses native children in reverse order and does not exclude a regular native view solely from Android visibility, so the hidden tab item subtree could win touch targeting over visible React controls at the bottom of the selected scene.

The patch makes the native bar implement ReactPointerEventsView: it returns AUTO while visible and NONE while hidden. It also reports actual holder layout changes instead of deduplicating on the unchanged root view size.

User impact

• bottom actions remain at their original coordinates and become clickable
• message and assistant selection toolbars, Provider actions, model pull actions, MCP chrome, and Assistant detail share the corrected native-container behavior
• visible Android tabs retain their existing click and long-press behavior
• iOS and application-level bottom background styling are unchanged

Validation

Freshly run after applying the two commits to the latest v0.2:

• patch guard: 3 tests
• pnpm typecheck:app
• targeted oxfmt --check
• pnpm packages:build
• ./android/gradlew -p android :app:compileDebugKotlin

The identical native patch was also regression-tested on the Cherry_API_36 Android emulator at 1080x2400. The message selection button remained at (32,2221)-(216,2342), and a tap at (124,2282) changed the state from “select all / delete disabled” to 18 selected items / delete enabled. Assistant selection, Provider model pull/detail, Assistant detail, hide/show transitions, process relaunch, and all five visible native tabs also passed. No MCP instance was created for testing.

Scope

This branch is based directly on the latest v0.2; it has no dependency on #518. The bottom white/background styling is intentionally unchanged.

[eeee0717]

The layout part of this patch addresses the same root cause as upstream callstack/react-native-bottom-tabs#557, with an existing fix in #558 (and the related startup-size fix in #556).

Could we align the overlapping layout change directly with upstream #558, and keep only the Cherry-specific addition on top?

In particular, #558 keeps the container listener and has both it and the layoutHolder listener call reportLayoutHolderSizeIfChanged(). This PR instead removes layout reporting from the container listener, uses callback bounds, filters zero sizes, and also changes setTabBarHidden() to explicitly call requestLayout(). Since changing Android visibility already requests layout, the extra local divergence does not appear necessary for the reported bug.

The ReactPointerEventsView / PointerEvents.NONE change is not present in #558 and should remain: it addresses the separate case where the hidden native tab subtree retains stale bounds and wins React Native touch-target traversal.

Using "upstream #558 patch + the minimal pointer-events addition" would make the behavior and provenance clearer, and make this pnpm patch easier to remove once the upstream fix ships.

[AtomsH4]

Thanks — addressed in the latest revision.

I realigned the layout portion with upstream callstack/react-native-bottom-tabs#558:

• kept the container layout listener;
• both the container and layoutHolder listeners now call reportLayoutHolderSizeIfChanged();
• the reported dimensions come directly from layoutHolder;
• removed the zero-size filtering, callback-bounds behavior, and explicit requestLayout().

The only Cherry-specific behavior left on top is the ReactPointerEventsView implementation: the native bottom bar reports PointerEvents.NONE while hidden and AUTO while visible, preventing its stale bounds from winning React Native touch-target traversal. The patch guard now checks both the upstream-aligned layout behavior and this pointer-events addition.

Validation completed with the 3 patch-guard tests, pnpm typecheck:app, targeted formatting, pnpm packages:build, and Android Kotlin compilation. I also rebuilt and installed the APK on the Cherry API 36 emulator: the selection action remained at its original coordinates, tapping (124, 2282) changed the state to 18 selected items, visible native tabs still worked, and a final manual interaction pass confirmed normal behavior.

Thanks for pointing out the upstream alignment — the patch should now be much easier to compare with and eventually remove in favor of upstream.