fix(messenger): shrink the page list request when Facebook says the response is too large

[viethung0o0]

Summary

• Some Facebook users cannot connect Messenger at all: Graph answers GET /me/accounts with HTTP 500 {"error":{"code":1,"message":"Please reduce the amount of data you're asking for, then retry your request"}}, the page picker route throws, and they land on the generic "Something went wrong" boundary with no way forward.
• The page list is now fetched with a smaller page (50) and, when Meta still refuses, retried from the first page at 25 and then 10. Each retry starts over because a cursor minted for a failed page size cannot be resumed, so nothing is read twice. The 2000-page ceiling of the old limit=100 × 20 requests walk is kept at every page size.
• That specific reply is no longer retried by the HTTP client: re-sending the identical request never succeeds, so the three status-code retries only added ~6 s before the same failure. Meta's generic code 1 ("API Unknown", documented as transient) keeps the default retry.
• When even the smallest page fails, the picker renders empty with a red box carrying Meta's own sentence above the existing "No Facebook Pages found" state, instead of crashing the route. The generic copy messenger.selectPage.loadFailed is only used when there was no Graph error body to quote (timeout, DNS, malformed JSON).

Changes

Messenger integration

• integrations/messenger/src/lib/http-client.ts — isDataTooLargeGraphError (code 1, no subcode, Meta's "reduce the amount of data" sentence) and shouldRetryGraphRequest, wired into the shared ky retry.shouldRetry. Returns undefined for everything else so the existing status-code policy is untouched for all three Graph clients
• integrations/messenger/src/apis/auth.ts — fetchDirectPages walks /me/accounts through DIRECT_PAGES_PAGE_LIMITS = [50, 25, 10], restarting from the first page on each shrink; maxPages scales with the page size so the row ceiling stays at 2000. Any other error is thrown unchanged

Builder

• apps/builder/src/app/(no-sidebar)/channels/messenger/select/page.tsx — loadUserPages catches the failure, maps it through mapToChannelError, logs it (err key) and renders the empty picker with the provider's message. readProviderMessage uses UNKNOWN_ERROR.code from the SDK to tell "Graph answered" from "Graph never answered"
• apps/builder/src/features/integration-messenger/components/select-account.tsx — optional loadError prop rendered as a destructive Alert above the picker
• apps/builder/messages/*.json — messenger.selectPage.loadFailed in all 20 locales

Behaviour changes worth knowing

• /me/accounts is requested with limit=50 instead of 100 for every Messenger connect, so a user with more than 50 pages now makes one extra Graph call on the happy path
• connect-page.ts and reconnect-callback.ts also call getUserPages; their contract ({ pages, bmLookupFailed } or a thrown MessengerAPIException) is unchanged, they simply benefit from the smaller pages
• Worst case for a user who both triggers Meta's error late in a walk and has close to 2000 pages is up to 3 sequential walks inside the server render. The error is a per-response size limit and in practice fails on the first request of a page size, so the realistic cost is 3 requests

Test plan

• pnpm --filter @chatbotx.io/integration-messenger test — 36 files, 303/303
• apps/builder/__tests__/messenger-select-page.test.tsx, messenger-select-account.test.tsx, messenger-pages.test.tsx — 21/21
• pnpm lint (Biome, i18n-check, schema drift) clean
• pnpm --filter @chatbotx.io/integration-messenger check-types, pnpm --filter builder check-types — no errors in touched files
• messenger.selectPage.loadFailed present in all 20 files under apps/builder/messages/
• invariant-guard clean on the diff
• Reproduced locally by faking the Graph reply for limit > 10: picker shows the pages after the 50 → 25 → 10 backoff; with every size faked, the red box shows Meta's sentence above the empty state
• Manual on production with an affected account: connect Messenger, confirm the page list loads or the box shows Meta's message instead of "Something went wrong"
• No DB migration required — schema untouched