Provider modules compile in unconditionally: no feature gate to exclude unused providers and their hardcoded endpoints

### Summary

`rig-core` compiles all 25 provider modules unconditionally. There is no feature
gate that removes the ones an application does not use, so a binary that talks to
exactly one OpenAI-compatible endpoint still ships every other provider's
hardcoded base URL and the GitHub Copilot / ChatGPT OAuth device flows.

For most users that is only binary size. For anyone shipping into an environment
that is audited for outbound network capability it is a documentation burden that
cannot be discharged by configuration, because the strings are in the binary
whether or not any code path reaches them.

### What is in the binary today

`src/providers/mod.rs:94-119` declares every provider module with no `#[cfg]`:

```rust
pub mod anthropic;
pub mod azure;
pub mod chatgpt;
pub mod cohere;
pub mod copilot;
...
```

A `strings` over a release binary of an application that only uses
`providers::openai` finds, among others, `api.anthropic.com`, `api.cohere.ai`,
`api.groq.com`, `api.mistral.ai`, `router.huggingface.co`, `api.x.ai`,
`api.z.ai`, plus this, from `src/providers/copilot/auth/native.rs:6-9`:

```rust
const GITHUB_CLIENT_ID: &str = "Iv1.b507a08c87ecfe98";
const GITHUB_DEVICE_CODE_URL: &str = "https://github.com/login/device/code";
const GITHUB_ACCESS_TOKEN_URL: &str = "https://github.com/login/oauth/access_token";
const GITHUB_API_KEY_URL: &str = "https://api.github.com/copilot_internal/v2/token";
```

None of it executes unless the corresponding client is constructed. That is not
the point being made: the question an assessor asks is "why does this binary
contain an OAuth device-code flow for a service you say you do not use", and
"it is unreachable" is a harder answer to evidence than "it is not compiled in".

### Why it looks cheap to fix

I checked the coupling before filing, in the published 0.41.0 source. Outside
`src/providers/` there appear to be no non-test, non-doc references to any
provider module:

- `src/client/mod.rs:860` and `:961` are inside `mod tests`.
- `src/transcription.rs:104`, `:128` and `src/embeddings/builder.rs:29` are doc
comments.
- Everything else that names `providers::openai` is itself under
`src/providers/`, and those are the OpenAI-compatible providers reusing
`providers::openai` and `providers::internal`.

So a per-provider feature with the compatible providers depending on the
`openai` one looks mechanical:

```toml
[features]
default = ["reqwest", "derive", "rustls", "all-providers"]
all-providers = ["provider-openai", "provider-anthropic", ...]
provider-openai = []
provider-deepseek = ["provider-openai"]
provider-azure = ["provider-openai"]
# ... one line per OpenAI-compatible provider
```

plus `#[cfg(feature = "provider-x")]` on each `pub mod` line. Keeping
`all-providers` in `default` means no existing user notices anything.

### Would a PR be welcome?

I am happy to open one against `main` if the shape above is roughly what you
would want, or to adjust it (a single `providers` umbrella feature rather than
one per provider, for instance, if per-provider granularity is more surface than
you want to maintain).

I would rather send a PR than carry a `#[cfg]` patch in a vendored tree, since a
carried patch has to be rebased on every release and this looks like something
other users in regulated environments will want too.

Start by examining src/providers/mod.rs lines 94-119 to see the unconditional module declarations. Review Cargo.toml to understand the existing feature structure. The task is to add per-provider feature flags (e.g., 'provider-openai') and conditionally compile each module with #[cfg(feature = "provider-x")]. Ensure the 'all-providers' feature is in defaults to maintain backward compatibility. Test by building with different feature sets and verifying unused provider strings are absent from the binary.

Escrita pelo modelo de indexação a partir do texto da issue.