Agents window: make GitHub issue filing reliable across MCP, browser, and CLI

## Problem

Asking an agent in the Agents window to file a GitHub issue is repeatedly unreliable even when the machine already has sufficient GitHub access. The agent sees several overlapping surfaces with different capabilities and authentication stores, then bounces between them instead of choosing one reliable write path:

- GitHub MCP tools may be available, but the exposed tool set can support reading/searching without issue creation.
- The integrated browser has its own cookie session and can appear signed out even while other GitHub clients are authenticated. For a private repository this can look like a permissions problem or a 404.
- GitHub CLI may already be installed and authenticated through the macOS keychain, but the fresh Agent Host shell PATH may not include Homebrew locations such as `/opt/homebrew/bin`.
- A worktree adds repository/remotes context, but should not determine the target when the user explicitly names `owner/repo`.

The result is a long, confusing sequence of failed capability and permission assumptions for a task that should be routine. This has happened repeatedly when filing issues from Agent Host sessions/worktrees.

## Concrete failure sequence

1. In an Agents window session running from a worktree, ask the agent to file an issue in a specific GitHub repository.
2. The agent runs `command -v gh && gh auth status`.
3. `command -v gh` fails because `/opt/homebrew/bin` is absent from that shell PATH. Because of `&&`, authentication is never checked.
4. The agent concludes that GitHub CLI is unavailable rather than checking the standard installation location or the VS Code/application environment.
5. It switches to the integrated browser. That browser is signed out, so a private repository appears inaccessible.
6. It checks `GH_TOKEN` / `GITHUB_TOKEN`; neither is set, and incorrectly treats that as confirmation that no authenticated GitHub path exists.
7. In reality, `/opt/homebrew/bin/gh auth status` reports an active account with `repo` scope from the keyring, and `/opt/homebrew/bin/gh issue create --repo / ...` succeeds immediately.

The browser being signed out, environment token variables being absent, and `gh` not being on the non-login shell PATH are three independent facts. None means the user lacks GitHub permission.

## Expected behavior

A request such as "file this issue in `microsoft/vscode`" should use a deterministic GitHub write path and should not make the user understand the MCP/browser/CLI split.

Related:
- #316461 requests broader first-class GitHub Issues integration in the Agents window.
- #327788 documents another case where Agents-window GitHub auth and the independently authenticated `gh` credential store disagree.

## Environment

- Code - OSS 1.130.0 (`0840ef38a166bd0ec2d94d0b967760102bf1bcc7`)
- macOS 26.5.2 arm64
- GitHub CLI installed at `/opt/homebrew/bin/gh`, authenticated as the active account through the macOS keyring with `repo` scope
- Agents window / Agent Host session in a Git worktree