perf(mobile): speed up large Android threads

[shivamhwp]

Large Android threads can finish syncing while LegendList has no attached visible rows, leaving a blank feed until the user scrolls. Paginated prepends also changed the list-header height on the final page, which moved the title/feed anchor while Android restored visible content.

This draft stays mobile-only:

• keep Android loading, unavailable, and hydrated thread headers on the same geometry;
• recycle Android feed rows, reduce the Android draw window, and keep one row mounted at each list edge;
• wake the Android native row-attachment path once after LegendList's initial end positioning;
• keep a fixed-height history control through loading, additional pages, and “Beginning of thread” so final-page prepends do not change header height;
• retain the existing feed-derivation and review-highlighter reductions already in this branch.

This does not replace server pagination from #5493. It also does not duplicate #5585: that PR seeds the composer inset before the initial scroll; this one handles positioned recycled rows that still fail to attach/paint. The final #5585 diff applies cleanly on top of this branch.

Verification on eeb9a52b2, rebased onto upstream main at 89c320df0:

• signed-in preview development client on the API 36 Android emulator, using its existing T3 Connect account and three saved environments; no fixture or environment re-pairing;
• fafo about t3code: cold current-head feed became visible without a gesture after roughly 40–45s; 24 alternating full-height swipes left 19 visible text nodes and six copy targets, with no blank recycled viewport;
• dashboard thread: initial content became visible without a gesture after roughly 13s; its two older-page loads rendered in roughly 8–12s each; the final fixed control read “Beginning of thread”;
• title bounds stayed exactly [129,136]–[696,197] across initial loading, both prepends, the final-page transition, and every stress pass;
• the full-history dashboard stress pass rendered 201 frames with 45.27% modern jank, p50 32ms, p90 77ms, p95 93ms, p99 150ms, and 40 missed vsyncs;
• preview-dev-client PSS rose from about 1.98 GB before opening the dashboard thread to about 2.39 GB after full history and stress scrolling; these absolute dev-client values are diagnostic, not release acceptance numbers;
• 16 focused tests passed and mobile typecheck passed again after the rebase. Targeted lint, targeted formatting, and git diff --check passed on the implementation head before the rebase.

The native blank-until-gesture and title/header-shift failures are fixed in these runs, but the current emulator measurements are not merge-ready. Keep this draft until the final rebased head gets a physical-device release-profile A/B and the remaining thread-load latency and scroll-frame costs are profiled. An earlier same-device physical A/B on the broader mobile rendering scope improved p99 from about 150ms to 73ms and PSS growth from about 161 MB to 97 MB, but that is not a substitute for a final-head rerun.

Implemented with GPT-5.6 Sol in the T3 Code Codex harness.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 420b7305-60f5-4848-ac6f-01112731f5f9

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

🟡 Medium threads/ThreadRouteScreen.tsx:207

OpeningThreadRouteScreen renders LoadingScreen below an in-flow AndroidScreenHeader, but LoadingScreen independently adds paddingTop: insets.top. On Android the header already reserves the top safe-area inset, so the loading state double-counts the status-bar inset and shifts the centered spinner/message downward relative to the hydrated thread screen. Consider using a loading body that omits the top inset when rendered under this header.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/mobile/src/features/threads/ThreadRouteScreen.tsx around line 207:

`OpeningThreadRouteScreen` renders `LoadingScreen` below an in-flow `AndroidScreenHeader`, but `LoadingScreen` independently adds `paddingTop: insets.top`. On Android the header already reserves the top safe-area inset, so the loading state double-counts the status-bar inset and shifts the centered spinner/message downward relative to the hydrated thread screen. Consider using a loading body that omits the top inset when rendered under this header.

[shivamhwp]

Closing this draft because its scope now overlaps multiple focused efforts and combines thread loading, rendering, navigation, and title/layout stability changes. We should revisit the remaining performance work as smaller, independently measured PRs after the adjacent changes settle.