Allow users to choose card activity order

[bionicman]

Important

Wait for a maintainer to approve this issue before opening a PR. We'll signal approval with a comment or label. Feature PRs without an approved issue will be closed.

✨ Feature Request

Is your feature request related to a problem? Please describe.

On cards with a long history, reaching the latest comments and changes requires
scrolling through the whole activity feed. The comment editor is also at the
bottom of that feed, so the current oldest-first order makes the most frequently
used end the least accessible.

Some teams prefer the existing chronological history, while others work mainly
from the latest activity. A fixed order cannot serve both workflows well.

Describe the solution you'd like

Let each user choose whether a card's complete Activity feed is shown
oldest-first or newest-first.

• Keep oldest-first as the default, preserving the current behaviour.
• Put the comment editor at the newest edge: below the feed in oldest-first mode
  and above it in newest-first mode.
• Offer a compact toggle in the Activity header.
• Apply the order to comments and system events together so their chronology
  remains meaningful.
• Remember the choice as a personal browser preference; it does not change the
  card or another member's view.
• Keep newly submitted comments visible even when older activity is hidden
  behind pagination.

Describe alternatives you've considered

Reversing comments alone would break the chronology of the combined feed.
Separating or filtering comments and system events, as discussed in #477 and
#525, can reduce noise but does not answer which end of either history should be
immediately visible. Those proposals remain compatible with this preference.

The first iteration keeps the choice browser-local. It can later move to the
user account if the project adds server-backed display preferences.

Additional context

Newest-first card activity:

Oldest-first card activity:

Mobile

Implementation ideas (optional)

A working implementation is available in
habralab/kan:feat/activity-sort-order.
It keeps the preference out of shared card state, passes the requested direction
through the existing cursor-paginated activity query, and uses the public ID as
a stable tie-breaker for events with equal timestamps.

The branch includes repository, API, web and browser coverage for both orders,
pagination, persistence, editor placement and new comments beyond a pagination
gap. It has also been exercised against an imported card with 424 activity
records.

The first iteration now follows the maintainer direction: it exposes only the
Activity-header toggle and keeps the preference browser-local. I am happy to
adjust the interaction or split the implementation if another shape fits the
project better.

Would you like to work on this feature?

• Yes, I'd like to help implement this feature
• No, I'm just suggesting the feature

[hjball]

I think this is a sensible suggestion @bionicman

Couple points:

• If we're going to store in in account settings it should be stored in the db
• I think the first iteration can just store the decision in local storage when toggling (no need to add to account settings)

There's definitely more we can do to improve activity history, but this is a great start

[bionicman]

That makes sense. I initially wanted this to be DB-backed, but followed the
existing Account Settings pattern: Language and Font size live there yet use
localStorage. Kan has no shared DB-backed display-preference path, so this kept
the prototype narrow.

I agree that Account Settings implies cross-browser persistence. I propose a
non-null activitySortOrder (oldest or newest, defaulting to oldest) on
the user row, exposed through user.getUser and user.update to both
controls. It is global rather than workspace-level; anonymous public views keep
the default.

If that fits, I prefer the DB-backed version. Otherwise I can narrow the first
iteration to a header-only localStorage preference.