bug: a capped read of pending asks drops the longest-waiting ones (server sorts newest first, clients show oldest first) #3679

Summary

Within a priority, the server returns pending operator-queue items newest first, but the Workspace Inbox and the operator queue both display them oldest first. Both clients read one capped page (200 items). When more items are pending than the cap, the page the server returns leaves out the oldest items. Those are the asks that have waited longest, and neither client can then show them.

Context

• Found while planning abilityai/trinity-enterprise#856 (Inbox sort), 2026-10-13. Recorded there as a known inconsistency, with this bug filed separately because the fix is on the server.
• Server: src/backend/db/operator_queue.py::list_items orders by sort_time descending within a priority.
• Clients: the Workspace reads at most ASKS_READ_CAP items, and the operator queue requests limit: 200. Both then sort oldest first for display.

Acceptance Criteria

• With more pending items than the read cap, the longest-waiting items are always in the page a client receives.
• Server ordering and client display agree on age direction, and the agreed direction is stated in the code that defines it.
• A unit test seeds more pending items than the cap and asserts that the oldest item is returned.
• The Workspace Inbox's Newest and Urgency orders (ent#856) and the operator queue's Open tab keep their current visible behaviour for queues smaller than the cap.

Technical Notes

• src/backend/db/operator_queue.py (list_items), and the two client read paths named above.