feat(miners): add cursor pagination to pulls and issues endpoints

[Yurii214]

Closes #100

Summary

• Add cursor-based keyset pagination to GET /miners/:githubId/pulls and GET /miners/:githubId/issues
• New cursor and limit query params; responses include next_cursor
• Default page size 50, hard cap 200

Why

Unbounded miner endpoint responses can return hundreds of nested PR/issue rows. Pagination bounds payload size while keeping backward-compatible response shape.

Test plan

• npm run lint passes
• npm run build passes

[Yurii214]

Added cursor-based pagination for both miner endpoints with bounded page size and next_cursor support.
Lint/build are passing locally, and I’m happy to make any adjustments if you’d prefer a different cursor shape or limit policy.

[Yurii214]

Built against the current test branch and adds cursor pagination for both miner endpoints with bounded page size and next_cursor support.
Happy to adjust the cursor format or limit behavior if you'd prefer a different API shape.

[anderdc]

Clean implementation — shared module, input validation, and the keyset casing is consistent across cursor/predicate/order. One blocker: these endpoints are validator-facing and currently return all rows, and this flips the default to 50 unconditionally, which silently truncates what validators score on until they're updated to follow next_cursor. Gate the bounded default behind a MINERS_PAGINATION_ENABLED flag (default off) — via ConfigService/process.env, matching the existing config pattern — as #100's Backward-compatibility section specifies. The pagination params can stay live; just don't change the default page behavior until the flag is on.

[Yurii214]

Updated. Default unbounded responses are preserved unless MINERS_PAGINATION_ENABLED is enabled. Explicit cursor / limit requests still paginate, so validators won't be silently truncated before they follow next_cursor.