feat(core): generate TypeScript types from the GraphQL queries

[marcalexiei]

The queries moved to src/graphql/queries/*.graphql and their types are generated from
GitHub's schema instead of hand-written.

• scripts/generate-graphql-types.js validates each query against @octokit/graphql-schema and writes one file per query plus a shared common.ts,
  so a wrong field fails generation and a wrong variable fails tsc.
• pnpm check-graphql-types runs in CI, so the generated types can't drift.
• httpGraphQLRequest takes a generated document: the four *QueryResponse interfaces are gone and GRAPHQL_REPOS_FIELD is a real fragment.
  Untyped request stays exported for the backend, with a TODO for considering its removal.
• Fixed nullability the hand-written types got wrong
  • (a gist's owner and files[].name, user, repositories.nodes);
  • Lang.color is nullable again
  • parseOwnerAffiliations returns the schema's RepositoryAffiliation.
• graphql stays on 16: @octokit/graphql-schema needs ^16.

Warning

The four apps/backend contract snapshots were refreshed:
the recorded request text changed, the rendered SVGs did not.

[vercel]

@marcalexiei is attempting to deploy a commit to the martin-mfg's projects Team on Vercel.

A member of the Team first needs to authorize it.

[martin-mfg]

• According to https://the-guild.dev/graphql/codegen/docs/guides/vanilla-typescript, GraphQL Codegen would support code generation without a custom script. I understand that importing GitHub's schema, checking for left-behind generated files, etc. require a custom script. But I wonder if it would be possible to reduce/omit the custom generation logic? The less code we need to maintain, the better.
• This PR also contains the TypeScript migration for WakaTime. I guess this is not intended?

[marcalexiei]

The guide recommends @graphql-codegen/cli + client-preset (documentMode: 'string') with a
fetch helper.

Three things moved this PR off it:

• The CLI can't be installed here:
  its Babel chain pulls semver@6.3.1, which trustPolicy: no-downgrade rejects.
  The script drives @graphql-codegen/core directly.
• client-preset emits one file; we generate one per query plus a shared common.ts.
  Better fit here: each card already has its own fetcher / api / render file.
• TypedDocumentString drags @graphql-typed-document-node/core into the published types
  (it implements DocumentTypeDecoration), and is re-emitted per file once output is split
  per query. The local graphqlDocument.ts avoids both.

This costs a 253-line script and one post-process (dropping the Incremental type typescript-operations always emits).
Guide-style would cost 9 codegen devDeps instead of 5, a single file for all queries, and the phantom type in the published types.

P.S.: I reverted the WakaTime card migration.

[martin-mfg]

I have only looked at generate-graphql-types.js so far:

[marcalexiei]

I've addressed your feedback and made additional changes:

• JSDoc for types
• banner on top of each generated file
• dependabot group for the new deps

[martin-mfg]

Could we avoid this cast?
As far as I can tell, the cast is not correct, although currently it's not a problem in practice, because of how we use fetcher. Would it make sense to return Promise<GraphQLResponse<UserInfoQuery | UserReposQuery>> instead?

[marcalexiei]

• One fetcher per query, no more cast:
  all four GraphQL fetchers are built by createGraphQLFetcher(document, scheme) in common/http.ts, which absorbed httpGraphQLRequest.
• FETCH_MULTI_PAGE_STARS is parsed once in config.ts:
  • "true": every page,
  • a positive number: cap
  • anything else: one page.
• The pagination loop accumulates extra pages and clones/merges once; a null or non-advancing cursor stops it.
  A failing later page returns the first page's data with that page's errors and statusText.
• New tests: a numeric page limit with real cursor advancement, and an error on a page after the first.