Warn when GitHub GraphQL returns partial data

[jskoiz]

Verified against main at 715c52e.

Impact

A GraphQL response can contain both usable data and field-level errors. The hosted client intentionally throws only when errors arrive without data, but repository aggregation types and reads only data; any accompanying errors are silently ignored.

Affected repositories then receive null/unknown open pull-request counts, issue counts, or check rollups without the partial-data warning required by this project's architecture. The usable portion should remain visible, but it must not be presented as complete.

Reference: GraphQL-over-HTTP partial response semantics.

Concrete code references

• The GraphQL executor returns a response with both data and errors without throwing.
• Repository aggregation's response type omits errors and consumes only data.
• Missing GraphQL fields become null/unknown repository values.
• The architecture requires truncated or failed upstream results to emit warnings.

Acceptance criteria

• Repository GraphQL aggregation detects a non-empty errors array even when data is present.
• Valid returned nodes are retained and used; a partial field error must not discard the entire page/dashboard.
• The payload includes a sanitized repo counts warning that makes the incomplete enrichment explicit without copying raw upstream error text.
• Existing errors-without-data behavior remains a caught warning path, and pagination continues to retain successfully loaded earlier pages.
• No credentials, raw GraphQL variables, or potentially sensitive upstream details enter the warning or logs added by this change.

Test expectations

• Add a client fixture for a response containing both data and errors.
• Add a dashboard test that proves valid nodes survive while warnings records partial GraphQL enrichment.
• Cover a partial response on a later page so earlier page data is preserved.
• Run npm run test -- --project server and npm run check.

Dependencies / order

Independent.

Non-goals

• Failing the whole dashboard when partial data is usable.
• Returning raw GraphQL error messages to the browser.
• Adding automatic retries or changing the GraphQL query schema.
• Treating expected null fields without an accompanying error as failures.