Closes #3106.

What was wrong

Clicking a column header under server pagination sorted the current page. The user saw "sorted by this column" and got "these fifty rows are in order; page 2 starts over."

The sort was real. Its scope was not the one the screen implied — and it had no way out of data-table at all: it lived in two useStates with no callback, so the layer that issues the request could not see it even in principle.

#3096 made this more dangerous rather than less: before it, clicking a lookup header produced garbage order that nobody believed; after it, the same click produces a convincing alphabetical page. The credibility went up while the scope stayed a lie.

The shape of the fix

The table keeps no sort state of its own in manual mode. A private copy beside a controlled prop is the exact shape the defect had, so a test asserts the indicator follows the prop and not the click.

manualSorting is deliberately independent of manualPagination: what matters is whether data is one window of something larger, not who owns the pager. (A windowed related list paginates itself — that is PR 4.)

Decisions worth reviewing

• A header click replaces the order rather than appending. The column under the cursor is the one the list is sorted by. Multi-key orders still come from the sort builder, and headers render them numbered.
• It cannot ask for "no sort". The third click clears in client mode, which is meaningful there — the rows return to the order they arrived in. Across a server-paged collection there is no such order (objectstack#4363), so a header offering it would hand the user a worse lie than the one being fixed. Clearing stays with the sort builder, which can restore the view's default.
• Relational columns render no sort affordance under server sorting: a lookup column shows a related record's name while $orderby can only order by the stored id (objectstack#4256) — the same reason lookup 列排序按裸外键 id 排：服务端 $orderby 发平面 FK 字段，单元格却显示 $expand 后的标签 #3096 removed them from the toolbar's picker. Client-side sorting keys off the rendered label, so those headers stay live there.
• One sort, two controls. Sharing currentSort is what makes "does a header sort outrank the saved view's sort?" a non-question rather than a precedence rule someone has to remember.

Also fixed in passing

The header context menu's Sort Ascending/Descending items wrote internal state directly, bypassing the sort handler. Under manualSorting that would have been a menu item that highlights, closes, and changes nothing — the same class of defect one control over. Both now route through a single write path.

Tests

28 new cases across the three layers, including the composition neither package's own unit tests can reach (ListView → grid, via a stub object-grid).

A regression caught during the run is worth noting: the first draft put declaredSort behind a useMemo that sits below ObjectGrid's early returns — 91 tests failed with "Rendered more hooks than during the previous render". It is a plain expression now.

Related

• PR fix(data-objectstack): a string $orderby reaches the server as a sort, not a list of character indices (#3106) #3109 — string $orderby serialization (independent; broken on main today).
• objectstack#4367 — the server half: paging a sorted read is now a partition of the result set. This PR makes low-cardinality columns like status the most common sort key, which is what turns that latent property violation into a daily one.
• Follow-up PR — RelatedList's two sorting semantics in one card.

🤖 Generated with Claude Code