[Bug] PR closing issue references are truncated after the first page

[Desel72]

Description

das-github-mirror fetches PR closing issue references with a fixed first-page GraphQL cap:

closingIssuesReferences(first: 10) {
  nodes { number }
}

The returned nodes are stored directly as pull_requests.closing_issue_numbers:

const nodes = pr.closingIssuesReferences?.nodes ?? [];

return {
  closingIssueNumbers: nodes.map((n: { number: number }) => n.number),
  body: pr.bodyText ?? null,
  lastEditedAt: pr.lastEditedAt ?? null,
};

There is no pageInfo request and no pagination loop, so a PR that closes more than 10 issues silently drops every closing reference after the first page.

This affects validator-facing data:

• FetchProcessor.handlePrMetadata() writes the truncated array to pull_requests.closing_issue_numbers.
• For merged PRs, only the truncated issue set gets issues.solved_by_pr updated.
• pr_linked_issues and miner API linked-issue output can omit valid linked issues.

Steps to Reproduce

1. Create or backfill a merged PR whose body closes more than 10 issues in the same tracked repository, for example Closes #1, closes #2, ... closes #11.
2. Let the fetch-pr-metadata job run for that PR.
3. Inspect pull_requests.closing_issue_numbers or the miner API linked issues for that PR.
4. Inspect the omitted issue rows after the 10th closing reference.

Expected Behavior

All same-repository closing issue references are persisted in pull_requests.closing_issue_numbers.

Every linked issue that exists in the mirror can appear through pr_linked_issues, and every linked issue closed by a merged PR can have issues.solved_by_pr reconciled.

Actual Behavior

Only the first 10 closingIssuesReferences nodes are stored.

Any linked issue after the first 10 is missing from pull_requests.closing_issue_numbers, cannot appear in pr_linked_issues, and is not updated by the merged-PR solved_by_pr write in FetchProcessor.handlePrMetadata().

Environment

• OS: N/A
• Runtime/Node version: per packages/das/Dockerfile
• Browser (if applicable): N/A

Additional Context

Relevant code:

• packages/das/src/webhook/github-fetcher.service.ts
  • fetchPrMetadata() queries closingIssuesReferences(first: 10) without pageInfo.
  • The method maps only the returned first-page nodes into closingIssueNumbers.
• packages/das/src/queue/fetch.processor.ts
  • handlePrMetadata() persists the truncated closingIssueNumbers.
  • For merged PRs, it writes solvedByPr only for those stored issue numbers.

Duplicate check:

• Related but not same as [Bug] Mirror flattens cross-repo closing references, enabling false solver attribution #35 / fix(mirror): filter cross-repo closing refs #36: those address cross-repo closing-reference identity flattening. This issue is about same-repository closing references after the first page being omitted.
• Related but not same as Backfill can miss solved_by_pr links when PR metadata runs before issues exist #28 / Fix backfill race for issue solved_by_pr linkage #29: those address backfill ordering and missed solved_by_pr reconciliation when issue rows do not exist yet. This issue is about the source closingIssueNumbers array already being truncated before reconciliation.
• Related but not same as [Bug] Backfill truncates review and label history before miner scoring reads it #9 / fix: backfill nested pagination #10: those discuss nested pagination for reviews, labels, and label timeline events. They do not cover closingIssuesReferences in fetchPrMetadata().

Suggested fix:

• Request pageInfo { hasNextPage endCursor } on closingIssuesReferences.
• Page through all closing issue references for the PR before returning closingIssueNumbers.
• If combined later with the cross-repo fix from fix(mirror): filter cross-repo closing refs #36, preserve repository identity while paginating and filter to the PR's own repository before storing issue numbers.

[anderdc]

closingIssuesReferences returns 0-1 nodes in practice in this repo's data; a PR closing 11+ issues isn't a production scenario. Closing.