[ENHANCEMENT] Add a dedicated GitHub Copilot provider with sign-in, live model list, and host-reported capabilities #1971

Problem (one or two sentences)

Zoo Code can reach GitHub Copilot models only through the generic vscode-lm provider, which has no GitHub sign-in, treats every model as text-only, and takes capability data from static defaults instead of what VS Code reports for each model. As a result, Copilot users get no account feedback, lose image input, and see wrong or missing limits for newer models.

Context (who is affected and when)

Anyone who runs Zoo Code against Copilot-backed models through the VS Code Language Model API. This includes users on managed Copilot seats where it is the only sanctioned model route. Verified against main:

• Image input is dropped. vscode-lm-format.ts replaces image blocks with text placeholders such as [Image (base64): ... not supported by VSCode LM API], and getModel() hardcodes supportsImages: false. Vision-capable Copilot models therefore never receive the image.
• No account state or recovery path. The provider settings panel has no sign-in control and no signed-in account label. When the GitHub session is missing, expired, or the wrong account, the user only sees an empty or failing model list, and the fix has to be found outside Zoo Code.
• Capabilities are not derived from the model. Context window and related limits come from openAiModelInfoSaneDefaults or a static catalog. Models Copilot adds later report generic values until a Zoo Code release catches up.
• The model list does not follow Copilot. Models are registered asynchronously after the Copilot extension activates, and nothing pushes that change into the settings view.

Desired behavior (conceptual, not technical)

A dedicated GitHub Copilot provider in Zoo Code settings where the user can:

• sign in, reconnect with a fresh authorization, and open VS Code's account management from the provider panel, with the signed-in account shown;
• see the model list populate as Copilot registers models;
• see context window, image support, and tool support taken from what VS Code reports for the selected model;
• attach images and have them reach image-capable models as image data.

The existing VS Code LM API provider stays unchanged for models contributed by other extensions.

Constraints / preferences

• VS Code owns the GitHub session. Zoo Code must not read, display, or persist the access token.
• Capabilities must be read live and not saved into settings, so nothing goes stale.
• Minimum supported VS Code stays at 1.100. Image parts are used only when the host supports them.
• Be explicit about what the API does not expose. It reports whether a model supports tools, not how many it accepts, and it exposes no cache-control or cache-hit data. The UI must not imply per-model tool limits or cache savings.
• Signing in proves a GitHub identity, not a Copilot entitlement, so an account without Copilot access should sign in cleanly and show an empty model list.

Acceptance criteria

Given Copilot Chat is installed and the user selects GitHub Copilot,
When they click Sign in to GitHub,
Then the signed-in account is shown and the model list populates as Copilot registers models.

Given a model whose reported capabilities include image input,
When the user attaches an image,
Then the image is sent as an image part, not a text placeholder.

Given a model for which the host does not report image support,
Then the UI shows "Image support not reported" instead of "unsupported".

Given a newly released Copilot model,
Then its context window and image/tool support are shown without a Zoo Code code change.

Given the user clicks Reconnect GitHub,
Then a fresh authorization is requested instead of reusing the existing session.

But the access token is never displayed, stored, or logged, and the vscode-lm provider's behavior for non-Copilot models does not change.

Proposed approach

Add a githubCopilot provider that reuses the existing vscode-lm handler, restricted to the copilot vendor. Resolve capabilities from LanguageModelChat metadata, with the curated catalog used only as a cap or fallback. Handle sign-in, reconnect and manage-account in the extension host, and broadcast the model list to the webview as Copilot registers models. Implementation is in the linked PR.

Trade-offs / risks

• Shared code path. The new provider shares vscode-lm.ts and vscode-lm-format.ts with the existing provider, so the change touches code used by non-Copilot models. Regression tests cover both.
• No sign-out. VS Code gives extensions no sign-out API. The manage-account control opens workbench.action.manageAccounts, and signing out there affects every extension using the account.
• Limits stay outside Zoo Code. GitHub plan limits, premium-request allowances, organization policies, and backend rate limits still apply and are not surfaced beyond what VS Code reports.
• Alternative considered: extending the generic provider in place. That would mix Copilot-specific sign-in UX into a provider meant for any extension's models, so a dedicated provider that shares the handler was chosen.

Benefits

• Vision workflows work with Copilot models instead of silently losing the image.
• Sign-in problems are diagnosable and fixable from Zoo Code instead of requiring a hunt through VS Code and Copilot settings.
• New Copilot models work on release, with no catalog update or Zoo Code release needed to get correct limits.
• No stored credentials, so the security surface does not grow.