fix(bling): paginate list_orders_with_items by summary page (fixes #219)

[rapguit]

Summary

Fixes #219. list_orders_with_items (added in #179) re-fetched the entire order-summary list for the date range on every call and sliced client-side, so paging a large range cost O(pages × batches) summary requests — and those redundant requests shared the ~3 req/sec budget with the per-order detail fetches (real waste + timeout/rate risk on long ranges).

This fetches a single summary page per call instead: one /pedidos/vendas page, filter canceled within it, fetch details only for that page. Paging a range is now O(pages).

Changes

• Handler fetches one summary page keyed by page (no full-range while loop, no client-side slice).
• pageSize (optional, default 25, max 100) is passed straight through as the API limite, so a single cursor bounds both the one summary request and the detailed set. This keeps per-call latency in check — the detail phase runs 2-at-a-time with a 700ms gap, so ~25 orders ≈ 9s vs ~35s for a full 100. A caller hitting an MCP timeout on dense pages can lower pageSize. (This preserves the reason batchSize existed in feat(bling): add 6 new tools for order details, stores, statuses, products and warehouses #179 — bounded per-call cost — without the full-range re-fetch.)
• Names the canceled-status magic number as CANCELED_STATUS (2).
• Throws a clear error if dataInicial/dataFinal are missing (they are required, but the handler no longer silently lists all dates).
• Interface change (the tool was merged today in feat(bling): add 6 new tools for order details, stores, statuses, products and warehouses #179, no external consumers yet):
  • Input: batchPage / batchSize → page + pageSize.
  • Output: page, pageSize, fetchedOnPage, hasMore, nextPage (was batchPage/batchSize/totalOrders/fetchedRange/nextBatchPage). totalOrders is dropped — computing it required the full-range fetch this PR removes.

Behavior notes

• hasMore is summaries.length === pageSize (full page ⇒ maybe more; short page ⇒ last). pageSize is integer-coerced so a fractional value can't make hasMore false and stop paging early.
• With excludeCanceled=true, an intermediate full page that happens to be all-canceled returns orders: [] with hasMore=true — correct; the caller advances on hasMore/nextPage, not on orders.length.

Test

Added a unit test asserting exactly one summary request per call, keyed by page (pagina=3 when called with page: 3) plus a bounded detail-request count. Verified it fails against the pre-fix code (which always started its summary walk at pagina=1), so it's a genuine regression guard — not vacuous. Full suite: 148 passed / 32 skipped, tsc --noEmit clean, catalog audit HIGH: 0.

Review

Adversarially reviewed (two rounds): the review caught that the first version of the guard test was vacuous and that a full-100-order page reintroduced the MCP-timeout risk — both addressed here.