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

[zentradev-rabih]

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]:

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:

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:

[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.

[linear-code]

RIG-1440