Enterprise custom models with slash in the provider model ID can't be selected from /model picker (ID is served URL-encoded as %2F)

Look at the CLI's model picker and model selection logic, likely in files handling the /model command and model catalog parsing. The issue is about matching IDs: the picker receives a URL-encoded ID from the API but may be decoding it before comparison. Start by searching for where model IDs are compared or displayed. Check how the --model flag validation works. The fix involves ensuring the ID used for lookup matches the encoded form from the API. Test by adding a custom model with a slash in its provider ID and verifying the picker can select it.

Describe the bug

Custom models whose provider-side model ID contains a slash (e.g. deepseek/deepseek-v4.1-flash, z-ai/glm-5.3) appear in the /model picker but cannot be selected, trying to choose one leaves the previous model active. The picker also shows "-" for Context and Reasoning on these entries even though the /models API response includes capabilities.limits.

The CAPI /models response serves the ID with the slash URL-encoded:

"id": "myorg/OpenRouter/deepseek%2Fdeepseek-v4.1-flash",
"custom_model": {"key_name":"OpenRouter","owner_name":"myorg","owner_type":"enterprise","provider":"openaicompatible"},
"supported_endpoints": ["/responses"],
"capabilities": {"limits": {"max_context_window_tokens":1048576,"max_output_tokens":384000,"max_prompt_tokens":664576}, "supports": {"streaming":true,"tool_calls":true}}

Passing the decoded form fails:

copilot --model "myorg/OpenRouter/deepseek/deepseek-v4.1-flash"
✗ Model "myorg/OpenRouter/deepseek/deepseek-v4.1-flash" from --model flag is not available. Using "claude-sonnet-5" instead.

Passing the encoded form works and the model runs fine:

copilot --model "myorg/OpenRouter/deepseek%2Fdeepseek-v4.1-flash"

So the model itself is usable; only the picker's selection/lookup path is broken. It looks like the picker decodes the ID (or constructs one from the display name/path) and then fails to match it against the encoded ID in the catalogue.

Note on the ID format: we do not control this ID. The Github enterprise UI only takes the provider's model name (deepseek/deepseek-v4.1-flash); the myorg/OpenRouter/…%2F… composite ID is generated GitHub-side. OpenRouter model names all contain a /, so every OpenRouter-backed custom model is affected. The fix has to be in the CLI's ID handling (or in how the ID is generated), not in configuration.

Affected version

Copilot CLI v1.0.87 (Linux)

Steps to reproduce the behavior

1. In Github enterprise settings, add an OpenAI-compatible API key (OpenRouter base URL) and add model deepseek/deepseek-v4.1-flash, enable it and grant org access.
2. copilot logout && copilot login, run /model.
3. Observe the model listed with no values for for Context/Reasoning; try to select it and nothing happens.
4. copilot --model "<enterprise>/<key>/deepseek%2Fdeepseek-v4.1-flash" works.

Expected behavior

Custom models are selectable from /model, show their configured context/reasoning, and --model accepts the ID in the same form the picker displays.

Additional context

Workaround: launch copilot with the URL-encoded ID via --model or set it with /config model.