[Bug] GraphQL metadata and backfill paths ignore response errors, silently dropping mirror data

[volcano303]

Description

Several GitHub GraphQL paths treat an HTTP-successful response as valid without checking the GraphQL response errors field.

Affected paths:

• fetchPrMetadata
• backfillPullRequests
• backfillIssues

GitHub documents that GraphQL rate-limit errors can return HTTP 200, and resource-limit cases can return partial results with an error. The PR file-content path already checks body.errors, but the metadata and backfill paths do not.

Steps to Reproduce

1. Trigger a GitHub GraphQL response for PR metadata or backfill that returns HTTP 200 with an errors array and missing or partial data.
2. Observe that the mirror only checks res.ok before reading await res.json().
3. In fetchPrMetadata, observe that missing PR data can be treated as empty metadata:
   • missing closing issue nodes become []
   • missing body becomes null
   • missing lastEditedAt becomes null
4. Observe FetchProcessor.handlePrMetadata() persists those values to pull_requests.
5. In backfill paths, observe missing page data can terminate the loop instead of failing the job for retry.

Expected Behavior

GraphQL responses with errors should fail the current fetch/backfill attempt unless the code explicitly handles a known partial-data case safely.

The queue should retry transient GitHub errors instead of persisting empty/null metadata or ending a backfill early.

Actual Behavior

The mirror can treat a GraphQL error response as successful:

• PR metadata can be overwritten with empty/null values.
• Closing issue references can be cleared from pull_requests.closing_issue_numbers.
• Merged PR solver linkage can be missed.
• Backfills can terminate early without surfacing failure.

Environment

• OS: Any
• Runtime/Node version: Node 20
• Browser (if applicable): N/A

Additional Context

Relevant code:

• packages/das/src/webhook/github-fetcher.service.ts
• packages/das/src/queue/fetch.processor.ts

GitHub GraphQL error behavior reference:

• https://docs.github.com/en/graphql/overview/rate-limits-and-query-limits-for-the-graphql-api

The file-content GraphQL path already has a body.errors guard, so the fix should apply equivalent validation to PR metadata and PR/issue backfill GraphQL calls.