🐛 fix(redirects): paginate listRedirects to prevent silent truncation

[kud]

📄 Description

listRedirects requested /domain/domains/{domain}/webredirs with no pagination parameters. Gandi caps that endpoint at 50 results and returns them with no error, no warning, and no indication the list is partial — so gandi redirect list silently under-reported whenever a domain held more than 50 redirects.

Measured on a real domain: the API held 64 redirects, the CLI reported 50. The 14 missing entries were invisible to both the table output and --json, so any script consuming the JSON got a confidently wrong answer. Notably, the missing entries included a redirect the user had just edited, which is how the bug surfaced.

The fix pages through with ?page=N&per_page=100, accumulating results until a short page signals the end. It deliberately does not cap silently: if pages never run short after 100 iterations, it throws an error naming the domain, on the principle that a truncated list is indistinguishable from a complete one and so must never be returned quietly.

Tests added in src/lib/api.test.ts:

• single short page returns everything with exactly one request
• a full page followed by a partial page concatenates to the full total, asserting the page/per_page query params on both calls
• an exact multiple of the page size terminates correctly on the following empty page
• pages that never run short throw rather than return a truncated list

📽️ Screencast

No visual changes.

✓ How to Validate

1. npm install && npm run build
2. gandi redirect list <domain> on a domain with more than 50 redirects — confirm the count matches what's actually configured (previously capped at 50).
3. npm test — see the new pagination coverage in src/lib/api.test.ts (45 passing, up from 41).
4. npm run lint — clean.

🛠️ Developer Checklist

• Code is readable and maintainable
• Tests included and passing (npm test — 45 passing, up from 41)
• PR is atomic and focused on a single feature or bug
• Commits follow Conventional Commits

Validated locally: npm run lint clean, npm test (45 passing), npm run build (tsc) clean, and verified live against a real domain — the CLI now returns 64/64 redirects and the previously-missing record is visible. No further manual/exploratory testing beyond that was performed.