Sessions list "Filter by status" total count is inaccurate until fully scrolled (shows partial count, not true total)
Description
On the mobile/web Sessions list (Code tab), opening "Filter by status" shows a total count (e.g. "All 80") that does not match the actual number of sessions available. If you scroll the session list all the way down to the oldest sessions (triggering more infinite-scroll pagination loads), then reopen "Filter by status", the count jumps significantly higher (e.g. "All 413", with Archived going from 120 to 650).
This strongly suggests the count shown in the filter sheet reflects only the sessions currently loaded into the client via infinite scroll, not the true total from the backend. This is confusing because:
- Users assume "All 80" is the complete list of sessions and may think older sessions were deleted or hidden.
- There's no visual indicator that the count is partial/still loading.
Steps to reproduce
- Open the Sessions list on mobile (or web) shortly after opening the app.
- Tap "Filter by status" — note the "All" count (e.g. 80).
- Close the sheet, scroll the session list all the way to the bottom (oldest sessions), forcing more pages to load via infinite scroll.
- Reopen "Filter by status" — note the "All" count is now much higher (e.g. 413), and per-status counts (e.g. Archived) increased substantially too.
Expected behavior
The "Filter by status" sheet should either:
- Fetch and display the true total count from the backend immediately (not just what's been paginated into the client), or
- Clearly indicate the count is partial/loading (e.g. "80+ loaded" or a loading spinner next to the count) until the full list is fetched.
Actual behavior
The count silently shows a partial number that looks final, and grows without any indication as more of the list loads via scroll-triggered pagination.
Screenshots
(Attached by reporter separately if needed — screenshots show "All 80" before scrolling to bottom of session list, and "All 413" after scrolling to the very bottom.)