Sort a user's notifications unseen first

[alexdont]

The notification centre sorts newest first, which interleaves read and unread.
Opening a notification leaves it exactly where it was, so anything still
outstanding ends up scattered among things already dealt with — read a new
arrival and the older unread one is now sitting underneath it.

On an inbox of any size that means scrolling up and down hunting for what was
missed, which is the one question a notification centre exists to answer at a
glance.

The change

Unseen sort above seen; newest first within each group. Reading something drops
it below whatever is still outstanding, so the unread block stays contiguous at
the top.

order_by(query,[n],asc: fragment("? IS NOT NULL",n.seen_at),desc: n.inserted_at)

IS NOT NULL rather than an inverted is_nil, because false sorts before true
— unseen comes first without a negation to read past.

Applies to list_for_user/2 and recent_for_user/2.

Why it matters more in the bell

The dropdown shows ten. With plain newest-first, a notification already read
could push an unread one off the bottom entirely — so the badge counts something
opening the bell doesn't show. There's a test for exactly that.

Nothing shuffles while you're looking at it

"Seen" is only ever set by an explicit action, and on that click the bell either
navigates away or refreshes — so the reorder lands on the next look rather
than under the cursor. No change was needed there; worth stating because the
opposite would be worse than the bug.

Deliberately unchanged

admin_list/1 stays plain newest-first. "Seen" belongs to the recipient, and an
admin scanning everybody's notifications is reading a chronological record, not
working through their own inbox — sorting a shared audit feed by whether someone
else has read each row reorders it differently for nobody's benefit. Recorded in
the doc so the inconsistency doesn't look like an oversight.

Testing

Four integration tests, pinned against the database rather than a sort function,
since ordering is a promise the UI makes and this is what a host embedding the
bell actually gets:

• an unseen older notification outranks a seen newer one
• newest-first still holds within each group
• all-seen falls back to plain newest-first
• an unread notification is not pushed off the end of the bell by a read one

Mutation-tested: reverting to plain newest-first fails three of the four. The
fourth is the all-seen fallback, which correctly shouldn't change either way.

One note on the second test — my first version marked the two oldest as read,
where both orderings agree on the result and it proved nothing. It now marks the
two newest, so the expectation (b, a, d, c) differs from what newest-first
would give (d, c, b, a).

45 notification tests and 101 LiveView tests pass; credo --strict clean;
compiles with --warnings-as-errors.

One thing worth a look separately

n_recipient_inbox_index is (recipient_uuid, inserted_at DESC) WHERE dismissed_at IS NULL. It still serves the fetch, but the new sort key isn't in
it, so ordering happens in memory. Irrelevant at inbox sizes — retention prunes
at 90 days by default — but if these ever grow large the index wants
(recipient_uuid, (seen_at IS NOT NULL), inserted_at DESC). Not added here:
that's a migration, and the chain isn't mine to extend on a whim.

No version bump or CHANGELOG entry.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NTj7hm3fpCTcFvKLRtgppW