chore(backend): add pagination defaults and max limits enforcement across list endpoints

[GEEKYFOCUS]

Closes #236

---

Summary

This PR addresses issue #236 by implementing consistent pagination defaults and maximum limit enforcement across all list endpoints in the Callora-Backend repository. This improves API consistency, performance, and protects against unbounded queries that could be used as an application-layer DoS vector.

🧪 Implementation Details

• Core Pagination Helper: Updated src/lib/pagination.ts to support both offset/limit and page/limit pagination structures seamlessly.
• Default Limits: Enforced a DEFAULT_LIMIT of 20 and a MAX_LIMIT of 100 system-wide.
• Input Normalization: Parsed and safely clamped invalid inputs (e.g., NaN, negative numbers, floats, zeros, huge limits) to strict safety bounds.
• Controller Refactoring: Updated src/app.ts, src/routes/admin.ts, and src/routes/developerRoutes.ts to use the shared parsePagination and paginatedResponse helpers consistently.
• Repository Layer Updates: Extended UsageEventsRepository (both In-Memory and PostgreSQL implementations) to explicitly support pagination (limit and offset).
• Endpoint Improvements: Standardized response formats (providing both data and meta) and implemented a full public API listing for GET /api/apis mapping to the backend repository logic.

📋 Security and Data Integrity Notes

⚠️ Performance & DoS Protection: By strictly enforcing a MAX_LIMIT of 100, we prevent potentially expensive database queries that could return millions of rows, eliminating a common vector for application-layer Denial of Service attacks.

• Robust Input Sanitization: All incoming pagination parameters are safely parsed using radix 10 integers and clamped to exact bounds (limit 1-100, offset >= 0). This ensures we drop invalid query states and prevents SQL injection via numeric parameters.
• Universal Consistency: Using parsePagination as the Single Source of Truth guarantees that all current and future list endpoints behave identically.
• Graceful Degradation: If no pagination parameters are provided, the system seamlessly defaults to the first page (offset 0) with a sensible limit (20), ensuring predictable API responses without overwhelming either backend performance or client memory limits.

📁 Files Changed

• src/lib/pagination.ts - Centralized validation & pagination logic
• src/lib/__tests__/pagination.test.ts - Extensive new unit tests for edge cases
• src/app.ts - Refactored endpoints for consistent usage
• src/repositories/usageEventsRepository.ts - Type signature updates
• src/repositories/usageEventsRepository.pg.ts - Safe parameterized offset implementation
• src/routes/admin.ts - Admin metrics routes
• src/routes/developerRoutes.ts - Developer analytics routes

🚀 Test Results

▶ parsePagination
  ✔ returns defaults when no query params given
  ✔ parses valid limit and offset
  ✔ clamps limit to max 100
  ✔ clamps limit to min 1
  ✔ clamps offset to min 0
  ✔ handles non-numeric strings gracefully
  ✔ truncates floating-point limit via parseInt
  ✔ clamps a huge limit (Number.MAX_SAFE_INTEGER) to 100
  ✔ calculates offset based on page and limit
  ✔ uses default limit when only page is provided
  ✔ prefers page over offset when both are provided
  ✔ handles invalid page values gracefully
...
✔ parsePagination (2.98ms)

▶ paginatedResponse
  ✔ wraps data and meta into the envelope
  ✔ works without total in meta
  ✔ returns exactly "data" and "meta" top-level keys
...
✔ paginatedResponse (1.05ms)

ℹ tests 32
ℹ suites 2
ℹ pass 32
ℹ fail 0


- Coses (#236)

[GEEKYFOCUS]

Hello @maintainer.
Kindly review my pull request and merge, so the issue can be closed

[GEEKYFOCUS]

Hello @greatest0fallt1me I'm yet to receive my point for the issue fixed

[GEEKYFOCUS]

Hello Maintainer, I'm still yet to get my point and this issue has been merged. Please can you explain what's happening

[GEEKYFOCUS]

Hello Maintainer I'm yet to receive my point for the issue fixed