Summary

Reader UI assumed a fixed viewport captured at first render. A few host environments break that assumption — Windows Subsystem for Android (WSA), foldables, freeform multi-window, split-screen — so click-zone classification, page count, scroll amounts and the bottom-menu animation all kept the original viewport values after the host window changed size. There was also no keyboard support, which is the dominant input on desktop-class hosts like WSA.

This PR makes the reader layout reactive to viewport changes and adds keyboard page navigation.

android/app/src/main/assets/js/core.js

• Viewport units: reader.layoutWidth/layoutHeight now read window.innerWidth/innerHeight instead of window.screen.width/height. window.screen on Android returns the host monitor resolution (which on WSA stays at the desktop monitor size), not the WebView area, so it never matched clientX/clientY and never updated. Fixing this restores correct click-zone classification, scroll deltas and totalPages math in calculatePages().
• Resize listener (150 ms debounce): re-reads viewport, and in paged mode re-runs calculatePages() so column-based pagination follows the new width.
• Keyboard handler with INPUT/TEXTAREA/SELECT/contentEditable and Ctrl/Alt/Meta guards:
  • Paged mode: PgDown / ArrowRight / Space → next page; PgUp / ArrowLeft → previous page.
  • Scroll mode: PgDown / ArrowDown / Space → +75% viewport scroll; PgUp / ArrowUp → −75%.

src/screens/reader/components/ReaderFooter.tsx

• Replace SCREEN_HEIGHT from @gorhom/bottom-sheet (captured once at module load via Dimensions.get('window').height) with useWindowDimensions().height. The entering/exiting worklets target screenHeight - navigationBarHeight - 64 and screenHeight - 64; once the host window shrank, those targets fell off-screen and the bottom menu either drew at the previous viewport's bottom or never became visible.

Why

Tested on WSA where the host can be resized at any time. Before:

• Centre-of-screen tap classified as "left" because clientX / screen.width collapsed the entire WSA window into the leftmost ~50% of the original monitor → menu never opened in paged mode and pages never advanced.
• After resizing, the bottom menu animated to the previous viewport's bottom (off-screen).
• No keyboard navigation — desktop users had no usable input.

After: all three flows behave as expected. On phones / fixed-size devices behaviour is unchanged — innerWidth/Height equals the device width/height when the app is full-screen, the resize listener never fires, and the keyboard handler simply has no events to react to.

Test plan

• Phone: open a chapter; tap each click region in paged + scroll mode; swipe paged mode; pull bottom menu — no regression.
• WSA: open a chapter in paged mode; resize the WSA window; click centre → menu toggles using the new viewport.
• WSA: PgDown / PgUp / ArrowLeft / ArrowRight / Space all advance/retreat one page in paged mode.
• WSA: scroll mode + resize → bottom menu enters and exits at the bottom of the current viewport.
• Keyboard handler ignores key presses while focus is inside an <input> / <textarea> / contentEditable element, and ignores Ctrl/Alt/Meta combos so browser shortcuts (zoom, dev tools) keep working.

Notes

• 150 ms resize debounce avoids hammering calculatePages() during continuous drag.
• No new dependencies; both files only swap to APIs that already ship with React Native / the WebView.
• Pure UI fix; database / fetch / plugin code is untouched.
• Resubmission of #1825, which was auto-closed when the original fork was retired.