feat(providers): expose GitHub Copilot's opt-in 1M extended-context tier (e.g. claude-opus-4.8) in /v1/models

## Feature Request

**Provider(s) Involved:** GitHub Copilot (`github`/`gh` registry)

**Model(s) Involved:** `claude-opus-4.8` and other Copilot models that GitHub lists as supporting the "1 million token context window" extended capability (Claude Sonnet 4.6, Claude Opus 4.6/4.7/4.8, Claude Opus 5, Claude Sonnet 5, Claude Fable 5, GPT-5.3-Codex, GPT-5.4, GPT-5.5, GPT-5.6 Luna/Sol/Terra, Kimi K3 — see [GitHub's supported models doc](https://docs.github.com/en/copilot/reference/ai-models/supported-models#models-with-extended-capabilities)).

**Client Tool:** OpenCode (via `opencode-omniroute-auth`, which live-fetches `GET /v1/models` and falls back to models.dev for `context_length` when OmniRoute doesn't supply one).

## Problem

`GET /v1/models` reports a `context_length` of 200,000 for `github/claude-opus-4.8` (and presumably the other models above), which matches models.dev's tracked *default* context size for `github-copilot/claude-opus-4.8`. However, per GitHub's own docs, Copilot supports an **opt-in extended 1,000,000 token context window** for this model:

> "1 million token context window: ... When you select a supported model, you can choose between the default context size or the extended (1 million token) context."
> "The 1 million token context window is available in Visual Studio Code and Copilot CLI only."
> (Choosing it consumes more AI credits than the default context.)

So 200K is a correct *default*, but there's currently no way to expose/select the extended 1M tier through OmniRoute's GitHub Copilot provider — unlike, e.g., the existing `[1m]` custom-model-suffix convention used for direct-Anthropic connections (see #4816, #9167) which lets a connection expose a `*[1m]` variant model id for extended-context routing.

## Proposed Solution

Add support for a `github/[1m]` (or equivalent) variant for GitHub Copilot models that support the extended capability, which:
1. Reports `context_length: 1000000` in `/v1/models` for that variant.
2. Sends whatever additional header/flag the Copilot CLI / VS Code clients send to actually opt into the extended context server-side (so the higher limit is real, not just advertised).
3. Reflects the higher credit cost for that variant if OmniRoute tracks per-model pricing/cost multipliers.

This should follow the same pattern already established for other providers' `[1m]` context variants, restricted to only the specific models GitHub lists as supporting it (not all Copilot models).

## Additional Context

- Traced the current data flow: OmniRoute's `modelsDevSync/transform.ts` syncs `github-copilot` models straight from models.dev's `limit.context` field with no further transformation, and models.dev's `github-copilot.claude-opus-4.8.limit.context` is `200000` (verified live via `https://models.dev/api.json`) — i.e. today's 200K is not a sync bug, it's just that neither models.dev nor OmniRoute currently model the opt-in extended tier.
- Related prior work for other providers: #4816 (Kiro rejects `[1m]` suffix — doesn't support it), #9167 (custom `claude-opus-5[1m]` on a `cc`/Claude OAuth connection is respected), #9957 (1M Claude + Opus 5 in Claude Code), #1357 (CC Compatible connection-level 1M context toggle).

Start with modelsDevSync/transform.ts and trace how github-copilot models reach GET /v1/models. Compare the existing [1m] work referenced in issues #4816, #9167, #9957, and #1357, then investigate the opt-in signal used by Copilot CLI or VS Code. Done means supported GitHub Copilot models expose a selectable 1M variant, the request actually opts into it, and any higher cost is represented.

Written by the indexing model from the issue text.