feat(mcp): summarize_orders aggregation tool

[dougborg]

Problem

Reporting workflows — counts by status, age in current status, count of overdue, top-N customers by order count — require paginating list_orders per status today and aggregating client-side. For a tenant with thousands of orders this is expensive and slow, and most of the data is thrown away after the count.

Proposed shape

A new MCP tool summarize_orders that returns aggregated views:

```python
summarize_orders(
group_by: Literal["status", "due_week", "customer", "tag"],
filters: dict | None = None, # same shape as list_orders filters
)
```

Returns counts (and optionally min/max/avg of relevant numeric fields) per group.

Two implementation paths (choice depends on #30 / F3)

Path A — server has an aggregation endpoint

Thin wrapper over the server endpoint. Cheap, fast.

Path B — server doesn't aggregate

Client-side aggregation: paginate list_orders filtering as requested, group in-process, return counts. Add hard caps:

• Max items aggregated: 1000 (or whatever the auto-paginator's safety limit is)
• Truncation flag in response if cap is hit
• Warning in result UI

Path B is meaningful work and only makes sense if the user actually needs aggregations and Path A isn't coming. If F3 shows the server has nothing planned, this issue may be deferred indefinitely (workflow workaround: agent paginates and groups inline).

Acceptance

• If Path A: tool wraps the endpoint, returns typed result, has Prefab UI showing the breakdown
• If Path B: client-side aggregation with explicit caps + truncation flag + clear UI warning
• At minimum supports group_by="status" (most common ask)
• Help resource updated

Depends on

• area/spec: investigate StatusPro server capabilities for filter additions #30 (F3) — must know whether the server aggregates before scoping

Tracking

Part of epic #31, Tier 3. Deferrable — only ship after Tier 1 and Tier 2 land.

[dougborg]

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

GET /orders/summary and GET /orders/counts both return 404 — neither endpoint exists. status_age_gt is also silently ignored as a query parameter.

Re-scope:

• Upstream feature request for an aggregation endpoint. Even basic group_by=status with counts would be a big win for reporting flows.
• Stopgap (Path B from the original issue): client-side aggregation by paginating list_orders and grouping in memory. With a 478-order tenant this is fine; with thousands it gets expensive (multiple API calls + memory). Defer until a) someone needs reporting and b) we have a clear cap policy.

This issue stays low priority (P2) and probably should NOT ship until the underlying primitives (#36 P1 sort, possibly #34 R3 bulk outcomes for time-in-status calculations) are settled.