fix(backend): allow negative page values in PaginationQuerySchema for downstream clamping

[CathyZaks]

Summary

Fix PaginationQuerySchema.page validation to allow negative integer strings (such as page=-1), allowing the downstream parsePaginationQuery function to safely clamp them to page 1.

Problem

PaginationQuerySchema.page used the regex /^\d+$/ with the validation error message "page must be a positive integer". When requests with negative page values (such as GET /api/transactions?page=-1) were validated by endpoints using PaginationQuerySchema or TransactionListQuerySchema, the request failed with a 400 Validation Error. However, the downstream pagination parser (parsePaginationQuery) already safely handles and clamps non-positive or negative page inputs to page 1 (returning 200). The validation schema was unnecessarily stricter than the downstream parser it feeds.

Solution

Update PaginationQuerySchema.page to validate against /^-?\d+$/ (page must be an integer), permitting negative integers like -1 to pass schema validation and reach parsePaginationQuery for safe clamping to 1.

Changes

• backend/src/types/validation.ts:
  Update page field regex from /^\d+$/ to /^-?\d+$/ and adjust error message to 'page must be an integer'.
• backend/src/__tests__/requestValidation.test.ts:
  Add unit tests verifying PaginationQuerySchema.safeParse accepts negative page values like page: '-1' for downstream clamping and rejects non-numeric page values like page: 'abc'.

Testing

• Ran ESLint on modified files: passed with 0 errors.
• Ran Prettier on modified files: clean.
• Ran Jest unit test suite requestValidation.test.ts: all 8 tests passing.

Closes #1367

[drips-wave]

@CathyZaks 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