feat(client): list_orders customer_email exact-match filter

[dougborg]

Problem

list_orders(search=…) is fuzzy across order number, name, customer name, and customer email — useful for "I have an order #" lookups but bad for "find every order belonging to customer X." A customer's full set requires either a too-broad search=email@example.com (also matches order numbers that happen to contain that string) or paginating everything and filtering client-side.

Reconciliation flows that key off external customer records benefit from exact-match.

Proposed shape

```
GET /orders?customer_email=foo@example.com
```

Exact match (case-insensitive). No partial matching — that's what search is for.

Acceptance

• Spec adds customer_email query parameter
• Generated client + helper kwarg + MCP tool
• Test verifying exact match (and that an order with email "foo@bar.com" doesn't return for customer_email=foo)
• Help resource updated

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 customer_email, email, and customer.email — all return baseline's 478. Verified using a real customer email from the baseline (sam.collentine@gmail.com) — that customer does not have all 478 orders, so the result confirms the parameter is unknown.

Re-scope:

• Upstream feature request for exact-match.
• Existing partial workaround: list_orders(search=<email>) performs a fuzzy match across order number, name, customer name, and email. Good enough for "does this customer have an order matching this email" lookups; not good enough when customer-email exactness matters (e.g., the email also happens to match an order number).