perf: paginate large JSON payloads in reports and admin-audit-log API routes (#670)

[Richiey1]

Closes #670

Summary

Certain API routes returned massive, unpaginated JSON payloads that consumed excessive memory on the client side. This PR adds pagination, filtering, and sparse field selection to the largest endpoints so clients only fetch the data they actually need.

What changed

• GET /api/reports now supports:

  • page / pageSize pagination (defaults: page=1, pageSize=20, max=100)
  • status filtering (pending, reviewed, or all)
  • fields sparse field selection (comma-separated)
  • Returns { items, total, page, pageSize, hasMore } envelope

• GET /api/admin-audit-log now supports:

  • page / pageSize pagination
  • adminAddress filtering (existing, preserved)
  • action filtering (new)
  • fields sparse field selection
  • Returns { entries, total, page, pageSize, hasMore } envelope

• src/lib/adminLog.ts updated to pass page and pageSize to the API instead of fetching the entire dataset and slicing client-side.

Tests

• Added unit tests for both endpoints covering pagination, filtering, sparse fieldsets, and pageSize clamping.
• All new tests pass. Pre-existing test failures in unrelated components remain unchanged.

Verification

• npm run lint — no new warnings or errors introduced by this change
• npm run typecheck — no new type errors in modified files
• npm run test -- --testPathPatterns="src/__tests__/app/api" — 12/12 tests pass

[drips-wave]

@Richiey1 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[sshdopey]

Auto-review failed (API error). Leaving PR for human review.

[davidmaronio]

the pagination core here is solid: sensible defaults, MAX_PAGE_SIZE clamp, NaN handling in parsePage/parsePageSize, the optional fields projection is a nice touch, and you added tests for both routes. the admin-audit-log action filter is also a genuine improvement.

blockers:

1. the PR contains messages/fr.json, messages/pt.json and src/i18n/routing.ts, which are #1028's changes (and those files are 100% untranslated english copies). they are unrelated to json pagination and will collide with #1028. please rebase onto main so the diff only contains the pagination work.
2. src/app/api/reports/route.ts:60 the GET response shape changes from a plain array to { items, total, page, pageSize, hasMore }. i do not see the admin moderation UI consumer updated in this diff, so anything doing (await res.json()).filter(...) breaks at runtime. either update all consumers in this PR or keep the old shape when no page param is passed.
3. src/lib/adminLog.ts:121 page = Math.max(1, Math.ceil(limit / pageSize)) with pageSize = min(100, limit) always evaluates to page 1 for any limit up to 100, and for limit > 100 it fetches a later page instead of the first N entries, which is wrong. you likely just want page 1 with pageSize = clamped limit.
4. src/lib/adminLog.ts:127 hasMore is destructured but never used, drop it or surface it to callers.
5. the identical parsePage/parsePageSize/pickFields helpers are duplicated in both routes, consider extracting them to a shared lib module.

note on CI: the lint/typecheck failures reference files this PR does not touch (WalletContext.tsx parse errors), so most of the red is a stale base and the rebase in ask 1 should clear it.

[davidmaronio]

following up: the branch hasn't changed since the review. it still contains messages/fr.json, messages/pt.json and src/i18n/routing.ts from #1028, and the response-shape and page-math items from the review are unaddressed. please rebase onto main and push the fixes so this can move.