BYOK: unrequested easoning_effort and snippy params sent to non-reasoning OpenAI deployments (400)

### What happened

Using the SDK in BYOK mode against an **Azure AI Foundry** account, every request to a **non-reasoning OpenAI deployment** (`gpt-4.1-mini`) fails at the provider with:

```
400 Unrecognized request arguments supplied: reasoning_effort, snippy
```

Anthropic deployments on the same account, same credentials, same code path work fine (`claude-haiku-4-5`, `claude-sonnet-4-6` — 14/14 successful calls in the same run).

### Why this looks like an SDK-side issue

Two parameters are reaching the provider that the calling application never set:

1. **`snippy`** — this string does not appear anywhere in our codebase. We grep for it across our entire application source and find zero occurrences. We have no API through which we could set it.

2. **`reasoning_effort`** — we do pass a `reasoningEffort` to `createSession`, but only after checking `capabilities.supports.reasoningEffort` from `listModels()` and dropping it when the model doesn't advertise support:

```ts
const supported = new Set(
(await sdk.listModels())
.filter((m) => m.capabilities?.supports?.reasoningEffort)
.map((m) => m.id),
);
const effort = supported.has(model) ? requested : undefined;

await sdk.createSession({
model,
...(effort ? { reasoningEffort: effort } : {}),
// ...
});
```

For a BYOK deployment name like `gpt-4.1-mini` this resolves to `undefined` and the key is omitted from the object entirely — yet `reasoning_effort` still appears on the wire.

So both parameters appear to be injected below the SDK surface, inside the bundled CLI binary.

### Impact

Non-reasoning OpenAI deployments are unusable through the BYOK path. This isn't only an inconvenience for model comparison — it removes the non-Anthropic fallback from a deployment whose only other models are Anthropic, so an Anthropic quota problem in-region would leave no working model at all.

### Environment

- `@github/copilot-sdk` **1.0.13** (bundled CLI **1.0.83**)
- Provider: BYOK / custom endpoint, `type: "openai"`, Azure AI Foundry
- Failing deployment: `gpt-4.1-mini` (OpenAI `2025-04-14`)
- Working deployments (same account/credentials): `claude-haiku-4-5`, `claude-sonnet-4-6`

### Expected

Neither `snippy` nor `reasoning_effort` should be sent to a provider/model that doesn't accept them — particularly `reasoning_effort` when the caller explicitly omitted it and the model catalog doesn't report reasoning support.

### Questions

- Is `snippy` intended to be sent to custom/BYOK providers at all? It looks like an internal parameter that should be scoped to the first-party backend.
- For BYOK deployments absent from the model catalog, what's the intended way to guarantee no reasoning parameters are attached? Is there a supported opt-out?

Bắt đầu từ đường dẫn BYOK createSession và listModels, sau đó kiểm tra việc xử lý yêu cầu của CLI đi kèm cho các deployment Azure AI Foundry OpenAI. Tái hiện với gpt-4.1-mini và so sánh yêu cầu gửi đi với đường dẫn Anthropic. Hoàn tất khi các deployment không reasoning không nhận reasoning_effort cũng như snippy, trong khi các mô hình reasoning được hỗ trợ vẫn giữ nguyên các tham số của chúng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.