fix(android, tabs): tolerate null screenKey during NativeTabs initial mount

[blackshrub]

Description

TabsContainer on Fabric Android can crash on cold-start with:

IllegalStateException: [RNScreens] screenKey MUST NOT be null

This happens when onAttachedToWindow fires and invalidates the navigation menu appearance before setScreenKey has propagated for every child TabsScreen. The downstream selectedTab getter calls getFragmentForScreenKey, which iterates tabsModel with TabsScreenFragment.requireScreenKey and throws on the first unbound fragment.

Crash stack:

TabsContainer.onAttachedToWindow
  → TabsContainer.flushPendingUpdates
  → TabsContainer.performContainerUpdate
  → TabsContainer.updateBottomNavigationViewAppearance
  → TabsAppearanceCoordinator.updateTabAppearance      (line 21)
  → TabsContainer.selectedTab                          (line 88)
  → TabsContainer.getFragmentForScreenKey              (line 600)
  → TabsScreenFragment.requireScreenKey                (line 13)
  → TabsScreen.requireScreenKey                        (line 45 → throw)

The unbound fragment is not a malformed config — it's a timing window. Fabric applies the child views to the tabs container before the prop-setting commit phase that calls setScreenKey. The fragment is in tabsModel, but its screenKey field hasn't been set yet.

Changes

Three surgical changes to TabsContainer.kt:

1. updateBottomNavigationViewAppearance — early-return if any fragment's screenKey is still null/blank. The next invalidation cycle re-enters this method once all fragments have settled, so deferring is safe.

2. getSelectedTabsScreenFragmentId — use the nullable tabsScreen.screenKey accessor instead of requireScreenKey. Unbound fragments compare to false and are skipped without throwing.

3. getFragmentForScreenKey — same nullable-accessor pattern; this is the lookup in the original crash stack.

Semantics are preserved: fragments without a bound screenKey are not matchable until they bind, and the next render cycle re-applies the appearance update once binding completes.

Test plan

Minimal reproduction (deterministic on Android Fabric, RN 0.83 + new arch + Reanimated 4 + expo-router 55.0.14):

// app/_layout.tsx
import { NativeTabs } from 'expo-router/unstable-native-tabs';

export default function Layout() {
  return (
    <NativeTabs>
      <NativeTabs.Trigger name="home">
        <NativeTabs.Trigger.Icon sf="house.fill" md="home" />
        <NativeTabs.Trigger.Label>Home</NativeTabs.Trigger.Label>
      </NativeTabs.Trigger>
      <NativeTabs.Trigger name="profile">
        <NativeTabs.Trigger.Icon sf="person.fill" md="person" />
        <NativeTabs.Trigger.Label>Profile</NativeTabs.Trigger.Label>
      </NativeTabs.Trigger>
    </NativeTabs>
  );
}

// app/home.tsx & app/profile.tsx → any simple `<View>` returning component

On react-native-screens@4.25.0, cold-start crashes 100% of the time with the stack above. With this patch, the appearance update is deferred one render cycle, all fragments bind their screenKey, and the tabs container settles normally.

Tested on Pixel 7 (Android 14), expo-router 55.0.14, React Native 0.83.6, react-native-reanimated 4.2.1, new architecture (Fabric) enabled, Hermes V1.

Checklist

• Included code example that can be used to test this change.
• For visual changes, included screenshots / GIFs / recordings documenting the change.
• Updated relevant documentation. (N/A — internal race fix, no public API change.)
• Listed all changes done in this PR in the changelog draft. (commit message describes the three call-site changes)
• Ensured that CI passes. (local Kotlin compile + existing test suite pass; logic-only changes)

[blackshrub]

Pushed a follow-up commit (0f5eead) — the initial guard set covered updateBottomNavigationViewAppearance but field testing on Pixel 9 (Android 16, RN 0.83.6, expo-router 55.0.14, Fabric, Hermes V1) surfaced a second crash path that bypasses the entry guards:

IllegalStateException: [RNScreens] No selected tab present
  at TabsContainer.getSelectedTab(TabsContainer.kt:88)
  at TabsAppearanceCoordinator.updateTabAppearance(TabsAppearanceCoordinator.kt:21)
  at TabsContainer.applyDayNightUiMode(TabsContainer.kt:591)
  at TabsContainer.onAttachedToWindow$lambda$11(TabsContainer.kt:271)
  at ColorSchemeCoordinator.applyResolvedColorScheme(ColorSchemeCoordinator.kt:108)
  at ColorSchemeCoordinator.setup$react_native_screens_release(ColorSchemeCoordinator.kt:73)
  at TabsContainer.onAttachedToWindow(TabsContainer.kt:270)

ColorSchemeCoordinator.setup fires the day/night callback in the same onAttachedToWindow window where fragment screenKeys still haven't propagated from JS. That path hits updateTabAppearance → selectedTab without crossing updateBottomNavigationViewAppearance, so guarding only that method leaves the second crash unmitigated.

Moved the guard to the selectedTab getter itself — fall back to the first bound fragment when navState.selectedScreenKey doesn't resolve, throw only when no usable fragment exists. The two helpers (getSelectedTabsScreenFragmentId, getFragmentForScreenKey) and the updateBottomNavigationViewAppearance early-return are kept as belt-and-suspenders.

Same minimal <NativeTabs> repro from the original PR description now starts cleanly on Pixel 9 cold-start.