Fix InboxListView NPE when switching tabs

[mikemilla]

Summary

openVisibleMessages was launched on Dispatchers.IO and called LinearLayoutManager.findFirstCompletelyVisibleItemPosition() / findLastCompletelyVisibleItemPosition() from a worker thread. Those APIs walk RecyclerView children and read View.getLayoutParams(), which is not thread-safe and races with the layout pass. Switching tabs while the list was still settling reliably reproduced a fatal NullPointerException inside ViewBoundsCheck.findOneViewWithinBoundFlags:

FATAL EXCEPTION: DefaultDispatcher-worker-6
java.lang.NullPointerException: Attempt to invoke virtual method
'android.view.ViewGroup$LayoutParams android.view.View.getLayoutParams()'
on a null object reference
  at androidx.recyclerview.widget.RecyclerView$LayoutManager$2.getChildStart(RecyclerView.java:8467)
  at androidx.recyclerview.widget.ViewBoundsCheck.findOneViewWithinBoundFlags(ViewBoundsCheck.java:219)
  at androidx.recyclerview.widget.LinearLayoutManager.findOneVisibleChild(LinearLayoutManager.java:2065)
  at androidx.recyclerview.widget.LinearLayoutManager.findLastCompletelyVisibleItemPosition(LinearLayoutManager.java:2038)
  at com.courier.android.ui.inbox.InboxListView$openVisibleMessages$1.invokeSuspend(InboxListView.kt:399)

Fix

• Switch the outer coroutine to Dispatchers.Main so LayoutManager and adapter reads happen on the UI thread.
• Read the visible index range, then subList(...).filter { !it.isOpened } on the main thread. Iterable.filter returns a fresh list, so it's safe to hand off to IO even if the adapter mutates afterwards.
• Defensively bound the visible range with coerceAtLeast(0) / coerceAtMost(messages.size) against stale indexes.
• Move only the network work (message.markAsOpened()) to Dispatchers.IO via withContext.

Performance

The fix is essentially free on the main thread:

• findFirst/LastCompletelyVisibleItemPosition() walk visible children only (~10–30 views), microseconds.
• subList(...).filter { !it.isOpened } iterates only the visible slice.
• Early return when nothing new is visible — no IO hop in the steady state.

A .toList() snapshot was tried in the first commit but dropped in the follow-up: it added O(totalMessages) main-thread work on every scroll event for no benefit, since adapter mutations are also confined to the main thread now.

Pre-existing follow-up (not in this PR)

recyclerView.setOnScrollChangeListener fires on every pixel of scroll, so a flick can launch dozens of openVisibleMessages coroutines per second. They mostly no-op via the early-exit, but the launches themselves aren't free. Worth throttling/debouncing or migrating to RecyclerView.OnScrollListener with onScrollStateChanged in a separate change.

Test plan

• Open the example app inbox, switch tabs rapidly while messages are loading — no longer crashes.
• Scroll the list and confirm visible messages are still marked as opened.
• Confirm setInbox, addPage, addMessage, removeMessage, and the scroll listener still call into openVisibleMessages cleanly (no thread-confinement asserts).
• Profile a fast scroll — main thread stays well under the 16ms frame budget.