feat(client): list_orders overdue + sort filters

[dougborg]

Problem

"Show me orders needing attention" is a recurring operational ask. Today it requires:

1. list_orders(due_date_to=today_isoformat) to filter to overdue
2. Client-side sort by due_date to surface the most-overdue first
3. Repeated for each status if filtering by status

Both overdue (server-side computed boolean) and sort (server-supported ordering) would collapse this to a single call.

Proposed shape

```
GET /orders?overdue=true&sort=due_date_asc
GET /orders?sort=updated_at_desc
```

sort should support at least: due_date_asc, due_date_desc, updated_at_desc, created_at_desc. Specific names match server semantics.

Acceptance

• Spec adds overdue (boolean) and sort (enum) parameters to GET /orders
• Generated client supports them
• Orders.list(overdue=True, sort="due_date_asc") helper kwargs
• MCP tool surfaces them
• Tests cover each sort option and overdue=true filter
• Help resource updated

Conversion path if server doesn't support these

If #30 (F3) shows the server doesn't filter on overdue or honor sort:

• Close this issue
• File an upstream feature request to the StatusPro team
• Optionally: implement client-side sort in Orders.list as a stopgap (auto-paginate then sort), with a clear docstring warning about cost on large result sets

Depends on

• area/spec: decide spec ownership model and execute #29 (F2) — spec ownership
• area/spec: investigate StatusPro server capabilities for filter additions #30 (F3) — server-capability probe

Tracking

Part of epic #31, Tier 2.

[dougborg]

Update from #30 probes (2026-04-29)

Server silently ignores every variant tested:

• overdue=true, is_overdue=true
• sort=due_date_asc, sort=due_date_desc, sort=updated_at_desc, sort=created_at_desc
• order_by=due_date, orderBy=due_date, sort_by=due_date

All return baseline's 478 with the same id ordering as the unfiltered list.

Re-scope:

• Upstream feature request for both overdue and sort — these are server-side capabilities.
• Stopgap (optional): client-side sort after auto-pagination. Acceptable on small tenants (~500 orders here) but breaks down on bigger ones; would also need a documented memory cap. Not recommended unless someone's actively blocked on "orders needing attention" reporting.