[juanpabloortizo]

The report tables listed every row at once (by client, agent, model, channel), the reply log paged 25 at a time and the conversation list 50, and no table could be ordered. A busy period turned the reports into a long scroll.

What changes

• Every report table pages with the shared TablePager: 5 rows by default, 5/10/25/50 to choose. The pager only appears once a table holds more than five rows.
• Every column header orders its table (SortHeader, new in components/table-sort.tsx). The first click sorts the way the column reads best (times and amounts high to low, names A to Z); the next reverses it. aria-sort is set on the header.
• Tables covered: Summary (by client, by channel), Costs (by client, agent, model, and every reply), Conversations, and the team table in the client portal's reports.

API

• GET /reports/replies takes sort (a key of REPLY_SORTS: date, contact, client, agent, channel, model, served by, duration, tokens, cost) and order. Newest first remains the default; unknown keys fall back to it. The CSV export follows the same order.
• The conversation list (agency and portal) orders by every column it shows except the ad referral ones; the existing four keys keep working.
• GET /reports/costs returns totals.estimated_replies for the period. The "Estimated" tile used to count only the replies on the page being read, which a five-row page would have made misleading.

Cleanup: the old prev/next pager (.report-pager, reports.prev, reports.next) is gone; nothing else used it.

Tested

• tests/test_cost_reports.py, tests/test_report_conversations.py, tests/test_reports.py, tests/test_report_operations.py: 13 passed, including new ordering tests and an injection-shaped sort key.
• tsc --noEmit and ESLint on the changed files: clean.
• In the browser against a local database: replies 1–5 of 82 sorted by tokens, conversations sorted by resolution time across pages (6–10 of 15), summary sorted by client, the estimated tile showing the period's 75.

🤖 Generated with Claude Code