Agent window: Claude account with a keychain `claude login` reads as "not set up" (1.135, macOS)

**Environment**
- VS Code 1.135.0, commit `08d4889f9ec4a1685d257b9b95de036c8e1ce1e5`
- macOS (darwin 25.6.0, arm64)
- Claude Code CLI 2.1.252 (native installer), signed in to a Max subscription via `claude login`
- Agent SDK 0.3.220 (the version `product.json` `agentSdks` pins)

**Symptom**

The Claude model picker in the agent window offers only Copilot-routed models. No Anthropic-account models appear, despite an active subscription login.

```
[Claude] Native account check: setUp=false, provider=firstParty, tokenSource=absent, apiKeySource=absent
[Claude] Models refreshed (merged). Count: 5, Claude Opus 4.7, Claude Opus 4.8, Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Haiku 4.5
```

**Why this looks like a defect rather than intended behavior**

#331739 replaced the filesystem sniffing with `accountInfo()` precisely so that this case works — its own message describes "a developer who pays for Claude directly hit a GitHub Copilot sign-in wall," and `isClaudeAccountSetUp`'s doc comment says the SDK must be asked because "a `claude login` credential lives in the macOS keychain, invisible to `process.env` and `~/.claude/settings.json` alike." On macOS that credential is still not recognized, so the population the PR targets remains locked out.

Same machine, same `$HOME`, no credential in env or settings — two opposite answers:

| asked via | answer |
|---|---|
| `claude auth status` (CLI directly) | `{"loggedIn": true, "authMethod": "claude.ai", "apiProvider": "firstParty", "subscriptionType": "max"}` |
| agent host's `accountInfo()` | `tokenSource` absent, `apiKeySource` absent → `setUp=false` |

Credentials are in the macOS keychain (`security find-generic-password -s "Claude Code-credentials"` finds the item); there is no `~/.claude/.credentials.json`.

**One detail that may point at the cause**

`claudeTransportMode.ts` notes that "`tokenSource` spells 'no credential' as `'none'` rather than absence." The agent host does not get `'none'` — the field is missing entirely. Driving the same SDK build from a terminal against a logged-out `HOME` *does* return `tokenSource: "none"`. So the host's probe appears not to reach credential resolution at all, rather than resolving it and finding nothing. That third state (`undefined`) is not distinguished from `'none'` by `isClaudeAccountSetUp`.

**Not an SDK-provenance artifact**

The SDK in `~/Library/Application Support/Code/agent-host/sdk-cache/claude/0.3.220/darwin-arm64/` is byte-identical to the official artifact at `https://main.vscode-cdn.net/agent-sdk/claude/0.3.220/darwin-arm64.tgz`:

```
sdk.mjs 1202bcd295a7c69cd0952f819a939e63071a3f2c3476a05f7e23425b01184fda
claude-agent-sdk-darwin-arm64/claude 8addc857f3fe64d5a0368af9ee50321b50afb4a6918ba3ef018ab84f5dbbe081
```

**Steps to reproduce**

1. On macOS, sign in with `claude login` (subscription; credential lands in the keychain).
2. Ensure `~/.claude/settings.json` contains no `env` credential keys and no `apiKeyHelper`.
3. Quit VS Code fully, reopen, start a Claude session in the agent window.
4. Check `~/Library/Application Support/Code/logs//agenthost.log`.

**Workaround**

`claude setup-token`, then `"env": { "CLAUDE_CODE_OAUTH_TOKEN": "…" }` in `~/.claude/settings.json`. The log then reads `setUp=true, provider=firstParty, tokenSource=CLAUDE_CODE_OAUTH_TOKEN` and the count goes to 10 (5 Copilot + 5 native). Requires storing a long-lived credential in a plaintext file, which the keychain login exists to avoid.

**Related**

- #331739 — the PR that introduced this check.
- #330464 — the 1.133 filesystem-sniffing version of this problem, closed by the stale-bot on Aug 21 without triage. The `ANTHROPIC_BASE_URL` workaround discussed there stopped working in 1.135, as reported in that thread on Aug 27.

I could not determine whether the fix belongs in VS Code (the assumption that `accountInfo()` surfaces keychain credentials) or in the agent SDK (not reporting them).