feat(client): list_orders id[] batch fetch

[dougborg]

Problem

After list_orders returns N order ids, fetching full detail today requires N separate get_order calls. For a 30-order reconciliation pass, that's 30 round-trips where one batch call should suffice.

Reconciliation against external systems (e.g. Katana) is the driving workflow — see epic #31.

Proposed shape

GET /orders?id[]=1&id[]=2&id[]=3

Returns the wrapped list response (same shape as a normal list_orders page), but containing exactly the requested orders.

The actual parameter shape (id[]=, ids=1,2,3, etc.) depends on what the server supports — see #30.

Acceptance

• OpenAPI spec adds the id[] query parameter to GET /orders (or whichever shape the server accepts)
• Generated client list_orders.asyncio_detailed accepts the new parameter
• Orders.list(id_in=[1, 2, 3]) helper added (kwarg name negotiable)
• MCP list_orders tool surfaces the new filter
• Test verifying batch fetch returns exactly the requested orders, in any order
• Help resource (statuspro_mcp_server/.../resources/help.py) updated

Depends on

• area/spec: decide spec ownership model and execute #29 (F2) — spec ownership model must be decided before adding undocumented params
• area/spec: investigate StatusPro server capabilities for filter additions #30 (F3) — server-capability probe must confirm the parameter shape

Tracking

Part of epic #31, Tier 1.

[dougborg]

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

The server silently ignores id[]=, ids=, and every other batch-fetch shape probed (id[]= real, ids= CSV). All return baseline's full result set (478 of 478 orders), confirming the parameter is unknown to the server.

No client-side workaround exists — without server support, batching is impossible.

Re-scope: This is now a feature request to file upstream with the StatusPro team rather than work we can do here. Recommend keeping this issue open as the tracker for the upstream ask, blocked indefinitely until upstream lands.