fix: do not block mount animation when only keyboard is animating (#2661)

[huextrat]

Problem

Fixes #2661

With BottomSheetModal + BottomSheetTextInput + autoFocus, the keyboard can open while didAnimateOnMount is still false. In that situation the sheet content can stay behind the keyboard. Focusing manually after the sheet is open (or after onChange) avoids the issue—a race between mount and keyboard animations.

Root cause

PR #2655 (ad41447, v5.2.10) added an early return in evaluatePosition for the mount phase:

if (!didAnimateOnMount.value) {
  if (animationStatus === ANIMATION_STATUS.RUNNING) {
    return;
  }
  // mount animation...
}

That correctly prevents the mount animation from overriding a close animation (e.g. forceClose), but it also treats any running animation the same way—including keyboard repositioning triggered by autoFocus. The mount path then never runs, and the sheet ends up misaligned with the keyboard.

Fix

Only skip the mount animation when a close is in progress:

• isForcedClosing (force close / modal dismiss path), or
• nextIndex === -1 (animating to the closed detent).

If the only RUNNING animation is keyboard-driven (nextIndex typically ≥ 0), the mount animation is not blocked.

Testing

• yarn biome check on the touched file (via pre-commit / lint-staged).
• Manual: reproduce Snack from [Bug]: Keyboard overlapping bottom sheet with autofocus #2661 — scenario with autoFocus should push content above the keyboard again.
• Regression: rapid present / close on BottomSheetModal (fix: prevent rapid present/close from freezing BottomSheetModal #2655) should still not freeze; close animations must still win over mount.

Related

• Introduced by: fix: prevent rapid present/close from freezing BottomSheetModal #2655 (ad41447)
• Reported: [Bug]: Keyboard overlapping bottom sheet with autofocus #2661

[dorupopacaliman]

Confirming the patch works, this needs to be released.

[gorhom]

thanks @huextrat for submitting this PR