fix(anilist): paginate custom lists before fetching metadata

[gusario]

Summary

Large AniList custom lists currently request full metadata for every entry before applying local pagination. This can make the GraphQL response too large or cause the request to fail for lists containing hundreds of entries.

This change first fetches lightweight entries containing only the score and AniList media ID, slices the requested page locally, and then fetches full metadata only for that page. Standard AniList status lists are unchanged.

Linked issue

Closes #<648>

Type of change

• Bug fix
• New feature
• Refactor
• Tests only
• Documentation only
• CI / tooling

Why this approach

AniList custom lists are returned through MediaListCollection, so the complete lightweight entry list is still needed to locate the requested custom list and preserve its configured sort order. Fetching only IDs and scores keeps this first response small, even for large lists.

After slicing the requested page, a second query fetches full metadata using id_in. Since AniList does not guarantee that this response follows the input ID order, the metadata is indexed by media ID and then reassembled by iterating over the original page slice. This preserves both the original ordering and each entry's score.

The tradeoff is that an uncached custom-list page now requires two AniList requests instead of one. However, the total payload is substantially smaller, and both requests continue to use the existing rate-limiting logic.

The metadata request is skipped when the requested page is empty.

Testing

• npm run build:backend — passed on Node.js 24.
• ESLint for addon/lib/anilist.ts — passed.
• npm run lint:backend — still reports five unrelated existing errors in addon/index.js, addon/lib/getMeta.js, and addon/lib/getSearch.ts.

Manually tested against a custom AniList containing 810 entries:

page 1 returned 20 items;

page 2 returned 20 items;

both pages reported the same total;

no media IDs overlapped between the two pages;

full metadata was present for returned items.

There are currently no automated tests covering this AniList custom-list pagination path. No automated test was added in this PR; the change was validated with the live integration check described above.

• I ran existing tests relevant to this change.
• I added or updated tests where needed.
• No tests were needed, and I explained why.

Documentation

• I updated documentation or comments where needed.
• [] No documentation updates were needed.

Author checklist

• This PR is focused on one concern.
• This PR is reasonably small and reviewable.
• I read and followed CONTRIBUTING.md.
• I can explain every code change in this PR.
• I will respond to review feedback myself.

AI usage disclosure

• No AI tools were used.
• AI tools were used for part of this PR, and I personally reviewed and verified all changes.

AI tools were used to help investigate the AniList pagination behavior, reason about the two-step query approach, and draft the implementation. I reviewed the resulting code and verified it with the backend build, linting, and a live AniList integration check.

[github-actions]

PR Guard

• All automated intake checks passed.

Maintainers may still close PRs that do not match project direction or review capacity.