Forward GitHub token in createSession/resumeSession RPC (#319029)

Forward GitHub token in createSession/resumeSession RPC (#318693)

The Copilot SDK has two GitHub-token slots:

  - Client-level (CopilotClientOptions.gitHubToken): hands the token to
    the spawned CLI subprocess via an environment variable. The CLI then
    does its own HTTP fetch to api.github.com to turn the bytes into an
    AuthInfo. If that fetch fails (slow/proxied network on the SSH host,
    transient 401, etc.) the CLI is left permanently unauthenticated
    because we also pass useLoggedInUser: false to disable the stored-
    OAuth fallback. Sessions created against that CLI inherit no
    AuthInfo and fail on first send with 'Session was not created with
    authentication info or custom provider'.

  - Session-level (SessionConfig.gitHubToken): the token travels inside
    the createSession RPC payload itself. The CLI resolves it as part of
    the create handler, so the session always carries its own AuthInfo
    regardless of whether the env-var bootstrap settled.

Pass the cached _githubToken through _buildSessionConfig so both
client.createSession and client.resumeSession get session-level auth.
This makes session start independent of the fragile env-var bootstrap
that fails for users with slow/proxied paths to api.github.com from the
remote. Add a regression test asserting the token is forwarded.

The client-level env-var path is left in place because client-scoped
SDK calls (listModels, listSessions, etc.) have no per-call token
override; those calls are tolerant of transient auth failures and are
not user-facing.

Fixes #318693

(Written by Copilot)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>