fix(messages): default topic message list to newest-first ordering

[jvorcak]

Problem

The default topic message view — non-continuous pagination, Newest origin, last-50 (shipped defaults: startOffset=-1/EndMinusResults, maxResults=50, continuousPaginationEnabled=false) — rendered rows in the backend's stream order, not newest-first. A customer reported it:

I would expect sorted by timestamp descending (and secondarily by offset descending). Particularly if we're getting last-50. Ideally you'd sort by offset, but of course offset isn't global across partitions and so timestamp is the next best thing.

Root cause

ListMessagesRequest has no sort-order field, and the backend's listMessages streams per-partition, so the merged result is not globally timestamp-sorted across partitions. The frontend never imposed an order on the default (non-continuous) view — it only sorted in the narrow continuousPaginationEnabled && EndMinusResults branch. So the default view showed whatever order the stream arrived in.

Note: this is not a regression from #2229 or #2486 — the default path has never sorted the multi-partition stream, and the backend doesn't sort it either. There is no request parameter that can make the backend return globally sorted results, so the ordering has to be imposed client-side.

Fix

Drive the table's own sorted row model via a sensible default for the existing sort URL param, instead of a bespoke row-list sort:

• DEFAULT_SORTING is now [timestamp desc, offset desc] (offset isn't global across partitions, so timestamp is the primary key and offset is a stable tiebreak — matching the customer's expectation).
• getSorting() treats an empty/unset sort as "use the default", so the newest-first default also applies for returning users whose persisted settings still hold the old empty sort.
• The Timestamp/Offset column headers now show the sort direction, and the sort is shareable/persisted via the URL.

Continuous-pagination mode disables header sorting, so the explicit newest-first sort is kept for its "Newest" fetch (now with the same offset tiebreak for determinism).

Scope / limitations

• This is a client-side sort of the loaded window. For the reported last-50 case that's the entire result, so it's fully correct. A globally-correct order across pagination boundaries would require a backend-side sort (separate, larger change).
• The default now applies to all non-continuous origins (including "From beginning"/custom), not only "Newest" — a consistent newest-at-top default; users can flip it via the column header.

Verification

• bun run type:check — passes.
• bun run lint — no new issues in the changed files.
• bun run test — no new failures (the one failing observability-page test also fails on the clean tree; unrelated).

🤖 Generated with Claude Code

[github-actions]

🚨 Registry drift detected

App: frontend · Scope: diff vs origin/master · Files: 1

	Count
⚠️ Outdated registry components	1
🛠 Locally-modified components	0
❓ Unknown to registry	0
🎨 Off-token palette colours	0
🔢 Ad-hoc utility classes	0

Components needing attention

Status	Component	Uses	Detail
⚠️ outdated	dropdown-menu	1×	installed 2.2.0 → latest 2.3.0

Refresh command:

bunx shadcn@latest add @redpanda/dropdown-menu --overwrite

Generated by lookout audit-changes.