Contacts: Sort by Last Seen does not sort by last seen; add has-unread filter

[MrSurly]

Bug: "Sort by Last Seen" does not actually sort by recency

lib/screens/contacts_screen.dart:88:

if (_sort == _SortOrder.lastSeen) return searched;

When the user selects "Sort by Last Seen," the screen does not sort at all -- it just returns the list in whatever order the underlying stream already provided, assuming that order is last-seen-descending. It is not.

The underlying stream comes from _buildContactsWithUnread() / getAllContactsWithUnread() (lib/database/daos/contacts_dao.dart, around lines 323-345 and 369-383), which applies a compound comparator in this priority order:

1. Non-repeaters before repeaters
2. Has unread messages before no unread
3. Has any message history before no history
4. Higher unread count
5. Only then, lastSeen descending

So any of criteria 1-4 can silently override recency. Confirmed report: two contacts ("P3", "Stormlove...") with message history and 0 unread were sorted above a third contact with a more recent "last seen: Just now," despite none of the three being repeaters and none having unread messages -- i.e. even after criteria 1, 2, and 4 are tied, criterion 5 (lastSeen desc) should have produced the correct order and did not. This suggests either the comparator is not actually the thing powering the observed list in this case, or there is a discrepancy between the lastSeen value used for sorting and the "X ago" text displayed to the user, worth checking as part of the fix -- e.g. whether the displayed relative time and the sorted lastSeen field can drift apart, or whether contacts_dao.dart:161 updateLastSeen (which appears to have no callers anywhere in the app) is dead code that should be wired up to keep last_seen current on actual contact activity rather than only being set once from the advert timestamp during contact sync (lib/repositories/contact_repository.dart:356).

Suggested fix: when _sort == _SortOrder.lastSeen, explicitly sort the list by contact.lastSeen descending in contacts_screen.dart, instead of trusting the source stream's order:

if (_sort == _SortOrder.lastSeen) {
  final sorted = [...searched];
  sorted.sort((a, b) => b.contact.lastSeen.compareTo(a.contact.lastSeen));
  return sorted;
}

Feature: add a "has unread" filter

_ContactFilter (lib/screens/contacts_screen.dart:19) currently has: endNodes, repeaters, hasLocation, noLocation, favorites. There is no way to filter the contacts list down to only contacts with unread messages -- unread status currently only affects sort priority (and only under the "Last Seen" sort, per the bug above), never inclusion/exclusion. Add a new filter option (same pattern as favorites) to show only contacts with unreadCount > 0.

[MrSurly]

Clarifying the acceptance criteria: sorting should reflect exactly the criterion the user selected, with no hidden/implicit tiebreakers layered in from elsewhere. This applies to all three _SortOrder modes, not just lastSeen:

• lastSeen: covered above -- should be a pure sort by contact.lastSeen descending, full stop.
• name: sorted.sort((a, b) => aName.compareTo(bName)) is fine in principle, but Dart's List.sort is not guaranteed stable, so any ties (equal names) can land in an arbitrary relative order rather than a deliberate one. Worth an explicit secondary key (e.g. hash or public key) so ties are deterministic rather than incidental.
• favoritesFirst: sorted.sort((a, b) => a.contact.isFavorite == b.contact.isFavorite ? 0 : ...) only distinguishes favorite vs non-favorite and returns 0 for everything else, so contacts within each group can come out in an arbitrary (unstable-sort-dependent) relative order. That needs an explicit, deliberate secondary sort within each group (e.g. name or lastSeen) rather than leaving it to sort-implementation happenstance.

None of the three modes should silently inherit ordering from _buildContactsWithUnread's repeater/unread/history grouping, and none should leave ties to whatever Dart's sort happens to do -- every mode should fully determine its own order.

[tmacinc]

I agree and also don't here. I do think an unread message should prioritize since the contact screen is also the DM chat screen. But I agree that dropping the others makes sense as they are legacy QoL from before sorting existed.

There are 2 architectural layouts that would work here, the current implementation uses the contacts page for 2 functions. 1 - a list of contacts that are synced with the companion, 2 - the DM chat page. Another method would be to combine all chats to a common page, eg. rename channels to chat (or similar), then display both channels, and contacts that have chat history, and only use the contacts page as a list of contacts. In the second case I would completely agree with the sorting logic above. This might make a few issues with chat persistence and the chat page losing DM contacts when the chats are lost.