[FEATURE] Runtime-selectable custom header per chat — configurable dropdown in third-party inference settings, with static or helper-script-provided values

### Preflight Checklist

- [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)

### Problem Statement

Claude Desktop in third-party (3P) inference mode already supports custom request headers via `inferenceCustomHeaders`, but the value is **static for the entire profile**: it is set once in the managed/bootstrap configuration and applies identically to every request from every chat. Changing it requires editing the configuration and restarting the app.

We need the **user** to be able to choose the value of such a header **at runtime, per individual chat**.

### Proposed Solution

Add the ability to define a configurable dropdown from the third-party inference settings, specifying:

- **Header name** — the custom header to attach to requests (e.g. `X-Team-Id`)
- **Dropdown label** — the name shown in the chat UI next to the model picker

The list of selectable values should be resolvable in either of two ways:

1. **Statically** — an explicit list provided in the configuration, or
2. **Dynamically** — an absolute path to a helper script that prints the available values, allowing the list to be computed at runtime rather than baked into the profile

The selected value is then sent as the configured header on every inference request originating from **that specific chat**, independently of the selected model or effort level.

### Credential passing to the helper script

For the dynamic case, it is essential that Claude Desktop can pass the helper script **the same credentials it uses for inference**. The helper typically needs to query an authenticated endpoint to determine which values the current user is entitled to, and duplicating or separately provisioning credentials just for the helper defeats the purpose. This would mirror the existing `inferenceCredentialHelper` pattern, but in the opposite direction — credentials flowing *to* the helper rather than being produced by it.

## Re-run model discovery with the selected header

Once the dropdown is active, when the user create a new chat, Claude Desktop should issue a **`GET /v1/models` request carrying the default value of that header** (eg. the first value).
Also, when the user expands it and manually selects a value, Claude Desktop should issue a **new `GET /v1/models` request carrying that header**, so the gateway can return the model list appropriate for the selected value.

The model picker would then reflect only the models actually available in that context.

## Environment

- Claude Desktop, 3P inference mode, gateway provider (Anthropic Messages API), Amazon Bedrock upstream
- macOS and Windows, managed via MDM

Happy to provide more detail on our setup if useful.

### Alternative Solutions

- **`inferenceCustomHeaders`** — static and global to the profile; requires an app restart to change. No per-chat granularity.
- **One `inferenceModels` entry per team per model** — pollutes the model picker with routing/billing metadata unrelated to model capability, multiplies every tier by the number of teams, and still cannot express "this whole chat belongs to team X." It also cannot express team-dependent model availability, since the list is fixed at configuration time.
- **Separate configuration profiles per team** — requires a full app restart to switch context, and cannot support two chats in different team contexts at the same time.

### Priority

High - Significant impact on productivity

### Feature Category

Configuration and settings

### Use Case Example

## Scenario

A user belongs to multiple teams/projects:

- Every inference request must carry a header identifying **which team/project the inference is being performed for** — this drives cost attribution, budget isolation, and access boundaries on our side.
- The **model list returned by `/v1/models` can itself depend on the team/project** — different teams have access to different model sets.

Our deployment routes through an in-house gateway implementing the Anthropic Messages API, with Amazon Bedrock upstream. The team/project context cannot be inferred from the model ID or from the user's identity alone, because the same user legitimately works across several of them in the same day.

### Additional Context

_No response_

No repository files or tests are named. Start by locating the third-party inference settings, chat model-picker entry point, and request code for GET /v1/models and inference calls. Trace how profile headers and inferenceCredentialHelper are handled; done means per-chat static or helper-provided values reach requests and model discovery refreshes after selection.

Written by the indexing model from the issue text.