fix(inbox): load all connected pages in the broadcast page selector instead of only 50

[viethung0o0]

Summary

• On a workspace with many connected pages, the broadcast page selector ("Trang Messenger") only ever offered 50 to choose from — a workspace with 500 pages saw "Select All - 50 options" and could not broadcast to the rest.
• The builder inbox store asked the paginated inbox API for everything (perPage: 999_999_999), but the shared pagination helper parsePagination clamps every list to maxLimit = 50. So the store silently held only the first 50 connected inboxes, and every surface reading from it — the broadcast page/flow selectors, and the inbox/contacts/reflinks filters — was capped with it.
• This adds a dedicated unpaginated path for "all connected inboxes of a workspace" and points the store at it. The paginated list and the public token API stay capped, so nothing on the documented API surface changes.

Changes

Business layer

• packages/business/src/inbox/service.ts — listAllConnectedByWorkspace returns every connected inbox for a workspace with no page limit. Its where and integration eager-load are extracted into shared helpers so list and the new method can never filter differently
• packages/business/src/inbox/schema.ts — extracts the shared inboxWithIntegrationsResource item schema and adds listAllConnectedInboxesRequest/Response (no page/perPage)

Builder

• apps/builder/src/features/inboxes/api/private.ts — listAllInboxesAuthenticatedAPI, an authenticated RPC-only procedure (no .route()), so "return everything" is not published on the OpenAPI/public surface
• apps/builder/src/features/inboxes/queries/index.ts — thin adapter to the service
• apps/builder/src/features/inboxes/provider/inbox-store.ts — the store loads from the new endpoint

Behaviour changes worth knowing

• The inbox store now returns every connected inbox instead of the first 50, so a workspace with more than 50 pages will fetch a larger, integration-joined result on the surfaces that read the store (broadcast selectors, inbox/contacts/reflinks filters). This is the intended fix — those surfaces must see all pages — but it is a heavier read for very large workspaces, matching the pre-existing listWithIntegrationsByWorkspace shape. A lighter or lazily-enriched variant is a reasonable follow-up if a workspace ever holds thousands of inboxes
• The paginated listInboxesAuthenticatedAPI and the public /v1/inboxes token API are unchanged and stay capped at 50 per page
• inboxWithIntegrationsResource still omits integrationThreads and integrationTiktok (a gap that predates this change and that no store consumer reads); adding them is a separate follow-up

Test plan

• pnpm --filter @chatbotx.io/business test — inbox suite 32/32
• apps/builder inbox store + broadcast suites — 8/8 store, broadcast/inbox surfaces green
• pnpm lint (Biome, i18n-check, schema drift) clean
• pnpm --filter @chatbotx.io/business check-types, pnpm --filter builder check-types — no errors in touched files
• invariant-guard clean on the diff
• Manual: on a workspace with more than 50 connected pages, open Create Broadcast → Messenger template, confirm the page selector lists and "Select All" counts every page, not 50
• No DB migration required — schema untouched