Configure the GitHub OAuth issuer for RFC 9207 (#8589)

Login on https://hud.pytorch.org/ fails with:

```
[next-auth][error][OAUTH_CALLBACK_ERROR] issuer must be configured on the issuer
  providerId: 'github'
```

### Cause

GitHub rolled out RFC 9207 (Authorization Server Issuer Identification),
so its OAuth callback now includes `iss=https://github.com/login/oauth`.
openid-client validates that param whenever it is present
(`openid-client/lib/client.js:584`):

```js
if ('iss' in params) {
  assertIssuerConfiguration(this.issuer, 'issuer');   // throws if issuer.issuer is undefined
  if (params.iss !== this.issuer.issuer) { /* iss mismatch */ }
```

next-auth's built-in GitHub provider sets no `issuer`, so `new
Issuer({issuer: undefined, ...})` makes the assert throw. Nothing
changed on our side — this broke from GitHub's rollout.

### Fix

Set `issuer` explicitly so both the assert and the equality check pass.

### Verification

Driving next-auth's real path (`parseProviders` -> `openidClient` ->
`assertIssuerConfiguration`):

```
without issuer     -> THROWS: issuer must be configured on the issuer
with issuer        -> callback SUCCEEDS
```

The merged provider is otherwise unchanged:

```
issuer      : https://github.com/login/oauth   <- matches the iss GitHub sends
authz url   : https://github.com/login/oauth/authorize
scope       : public_repo workflow             <- our override preserved
wellKnown   : undefined                        <- no OIDC discovery triggered
idToken     : false
checks      : [ 'state' ]
```

`wellKnown: undefined` and `idToken: false` are the ones worth noting —
setting `issuer` triggers OIDC discovery on some providers, but
next-auth v4 only does that when `wellKnown` is set explicitly, so this
stays a plain OAuth2 flow. The change is a no-op when GitHub is not
sending `iss`, so it is safe to land regardless of rollout state.

### Notes

- GitHub has **paused** the rollout, so login may currently succeed
intermittently depending on which server handles the callback. A
successful login is not evidence the bug is gone.
- next-auth 4.24.14+ ships this same value upstream, but `yarn.lock`
pins 4.24.11, so a build will not pick it up. Bumping is reasonable
housekeeping for a separate PR; this line stays a harmless no-op
afterwards.

Refs: https://github.com/orgs/community/discussions/192143,
langfuse/langfuse#13091

Author: huydhn

torchci/pages/api/auth/[...nextauth].ts

@@ -42,6 +42,9 @@ export const authOptions = {
     GithubProvider({
       clientId: process.env.GITHUB_CLIENT_ID!,
       clientSecret: process.env.GITHUB_CLIENT_SECRET!,
+      // GitHub now returns an `iss` param on the OAuth callback (RFC 9207), and
+      // openid-client rejects it unless the issuer is configured here.
+      issuer: "https://github.com/login/oauth",
       authorization: { params: { scope: "public_repo workflow" } },
     }),
   ],