fix(ScreenFooter): init animatedValue to 1 for opacity-based animations when visible

[adids1221]

Description

On Android, when animationType='none' (or animationDuration=0) and visible=true, the footer's animatedValue was initialized to 0 instead of 1. This caused the footer to render with opacity: 0 for at least one UI-thread frame, blocking touches in the footer area even though the footer appeared invisible.

Root cause

// before — only 'fade' started at 1; 'none' incorrectly started at 0
const animatedValue = useSharedValue(animationType === 'fade' && visible ? 1 : 0);

Both 'fade' and 'none' use the opacity path in useAnimatedStyle. Only 'slide' uses translateY and legitimately starts at 0. So the initial value guard should be !== 'slide', not === 'fade'.

Fix

// after — both 'fade' and 'none' start at 1 when visible; no invisible-but-blocking frame on mount
const animatedValue = useSharedValue(animationType !== 'slide' && visible ? 1 : 0);

Why this doesn't regress hide-on-scroll for animationType='none'

PR #4009 broke hide-on-scroll by changing else → else if (animationType === 'fade') in useAnimatedStyle, which excluded 'none' from receiving opacity. PR #4019 reverted that. This fix is orthogonal — it only touches the initial value, not the style callback. The else branch (restored by #4019) still drives opacity to 0 when visible becomes false.

Changelog

ScreenFooter - fix touch blocking on Android when animationType is 'none' and footer is visible on mount

Additional info

Related: #4009, #4019

[github-actions]

✅ PR Description Validation Passed

All required sections are properly filled out:

• ✅ Description
• ✅ Changelog
• ✅ Additional info

Your PR is good for review! 🚀

---

This validation ensures all sections from the PR template are properly filled.