CopilotClient fails with "No GitHub OAuth token or Copilot HMAC key provided" on Linux only, with a valid gitHubToken set

`CopilotClient` (Node.js SDK, `@github/copilot-sdk` v1.0.13) fails every model-inference call (`models.list()`, and any session `chat`/`sendAndWait`) with:

Plain text

```
Execution failed: InvalidArg, No GitHub OAuth token or Copilot HMAC key provided

```

or, for `models.list()` specifically:

Plain text

```
Request models.list failed with message: Not authenticated. Please authenticate first.

```

...even though a valid `gitHubToken` is explicitly passed to the `CopilotClient` constructor. The **exact same application code, same GitHub account, same token** works correctly when run locally on Windows, and fails 100% of the time on Linux (Kubernetes/EKS). No BYOK or sub-agent/`task` tool is involved — this is the top-level session's very first call.

### Environment

- **SDK**: `@github/copilot-sdk` v1.0.13 (latest at time of filing), native runtime (stdio transport, not in-process/FFI)

- **Failing environment**: Kubernetes (EKS) pod, `node:22-slim` (Debian) base image, Node 22

- **Working environment**: local Windows 11, same Node version, same code

- **GitHub host tested**: both `github.com` (default) and a GitHub Enterprise Cloud with Data Residency tenant (`*.ghe.com`) — identical error on both, so it is host-independent

### Client construction (simplified)

TypeScript

```
const client = new CopilotClient({
mode: 'empty',
gitHubToken: accessToken, // valid gho_ OAuth App token, confirmed non-empty at this point
logLevel: 'debug',
});
await client.start();
const models = await client.models.list(); // fails here, ~15-30ms after session start

```

### What we've ruled out

- **Token type**: reproduced identically with both a `ghu_` (GitHub App user-to-server) token and a `gho_` (OAuth App) token.

- **`useLoggedInUser`**: confirmed via SDK source it already defaults to `false` whenever `gitHubToken` is set.

- **Ambient/cached credentials**: no OS credential manager entries involved on Linux; removing all cached Windows Credential Manager entries didn't change Windows (still works).

- **Env var pollution**: added diagnostics dumping every `GH_*`/`GITHUB_*`/`COPILOT_*` key present in `process.env` — nothing unexpected present.

- **Network/firewall**: confirmed the pod can reach both `api.` and `copilot-api.` (real HTTP responses, not connection errors).

- **`GH_HOST`/`GH_TOKEN`/`GH_ENTERPRISE_TOKEN`**: removed all three entirely (falling back to the default `github.com` host with only the explicit `gitHubToken`) — **identical error**, ruling out host-scoped env vars as the cause.

- **`InProcessRuntimeConnection`**: not applicable/not in use; confirmed via docs it doesn't honor per-client `gitHubToken` anyway, so not a viable workaround.

- **Missing `libsecret`/D-Bus Secret Service**: confirmed absent from the `node:22-slim` container (`ldconfig -p`/`dpkg -l` show nothing). Extracted strings from the Linux `runtime.node` binary show a `keyring_core` + D-Bus Secret Service credential backend, but also a `"...continuing without credential"` string suggesting graceful degradation is intended — inconclusive, but worth noting as a possible contributing factor since we already set `COPILOT_DISABLE_KEYTAR=1` via `mode: 'empty'`.

### Confirmed facts

- Diagnostic logging confirms the token reaches `CopilotClient` non-empty and correctly shaped at construction time.

- Per SDK source, this sets `COPILOT_SDK_AUTH_TOKEN` in the runtime env and passes `--auth-token-env COPILOT_SDK_AUTH_TOKEN` to the spawned CLI process — confirmed happening correctly at the JS layer on both platforms.

- Failure happens within ~15-30ms of session start, immediately followed by session error/shutdown — before any model call actually executes.

### Possibly related

This may share a root cause with #559 / #557 ("Built-in `task` tool fails with 'No GitHub OAuth token' in BYOK/Azure AI Foundry deployments"), where a community deobfuscation traced the same exact error string to a `CopilotApiClient`/`sweagent-capi` construction path that gets created without either credential under certain conditions. Our case differs (no BYOK, no sub-agent involved, fails on the very first top-level call) but the error text and general "client constructed without a resolved credential" shape look related.

### Ask

- Is `gitHubToken`/`--auth-token-env` a tested/supported path on the Linux native runtime specifically?

- Any known Linux-only regression or required container dependency (e.g. `libsecret`/D-Bus) for this auth path?

- Any way to get more diagnostic output from the native runtime for this failure — it's nearly silent on stderr even with `logLevel: 'debug'`.

Bắt đầu với mã nguồn SDK đặt COPILOT_SDK_AUTH_TOKEN và truyền --auth-token-env, sau đó tái hiện lỗi bằng runtime Linux native trong môi trường node:22-slim. Kiểm tra đường dẫn credential và xác thực của runtime.node, bao gồm cả hành vi keyring/D-Bus đã được đề cập. Hoàn tất nghĩa là xác định nguyên nhân dành riêng cho Linux và ghi lại hoặc kiểm thử một bản sửa được hỗ trợ cho models.list() và các lệnh gọi session.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.