bug: Workspace asks read silently stops at 200 rows with no total #3059

Summary

GET /client-portal/asks stops at 200 rows (src/backend/client_portal/asks/service.py:196, limit=200) and returns no total. A viewer with more than 200 asks (pending plus ended in the last 7 days) silently loses the oldest ended ones. With more than 200 pending asks, pending ones are lost too. Nothing on screen says the list is cut.

Context

The Workspace Inbox's All tab (trinity-enterprise#610) promises "pending asks always, ended asks for 7 days". Pending asks sort first, so they are complete up to 200. PR #3054 adds an honest footer ("Showing your 200 most recent asks") when exactly 200 come back. The real fix needs a total and paging, which changes the contract, so it is split out here.

Acceptance Criteria

• The asks read returns a total (or has_more) alongside the page.
• The client can page past 200 (a cursor or offset), and the Inbox's "Show more" fetches the next page when the client-side window is exhausted.
• Pending asks are never dropped while ended ones are shown.
• Requirements updated first (Rule Fix: Add missing Docker labels to system agent container #1) for the contract change. The api-endpoints row is updated.
• The honest-cap footer from feat(workspace): the Workspace Inbox — Action, Unread, All, a reading pane (trinity-enterprise#610 PR A) #3054 is removed once the total exists.

Technical Notes

• db/operator_queue.py already orders pending before ended. Paging should keep that order stable across pages (tie-break on id).