feat(miners): add cursor pagination to windowed POST pulls/issues endpoints

[anderdc]

Why

The per-repo windowed POST /api/v1/miners/:id/pulls and /issues endpoints run unbounded: every matched PR/issue executes the inlined labels + linked_issues subqueries, so a high-volume author's request exceeds the validator's 30s read timeout. The validator then catches the error, falls the miner back to a stale cached evaluation, and the miner's new PRs/issues never get ingested.

Observed live: POST /miners/156195510/pulls (kiannidev, 621 PRs) reliably read-times-out at 30s × 3 attempts; same for the other two highest-volume miners (UIDs 29, 212). The mirror has the data — it's purely query latency on the unbounded windowed read.

What

Mirror the cursor pagination already shipped for the GET paths (#126) onto the windowed POST variants:

• getPullRequestsByRepo / getIssuesByRepo accept an optional pagination arg: keyset on (created_at, LOWER(repo_full_name), number), deterministic matching ORDER BY, LIMIT, and a next_cursor in the response.
• POST /pulls and /issues accept optional ?cursor= / ?limit= query params (body stays the since_by_repo map), routed through the existing parsePaginationQuery.

Compatibility

Default responses (no cursor/limit) stay unbounded and unchanged, so validators that have not yet adopted paging are unaffected. The companion gittensor change (validator follows next_cursor) ships only after this deploys.

Verify

curl -s -X POST "https://mirror.gittensor.io/api/v1/miners/156195510/pulls?limit=2" \
  -H "Content-Type: application/json" \
  -d '{"since_by_repo":{"phase-rs/phase":"2026-05-12T00:00:00Z"}}' | jq '.next_cursor, (.pull_requests|length)'

format:check, lint, and nest build all pass.