Custom OpenAI-compatible wildcard discovery advertises OpenAI catalog for Tinker

Finding: In an external report against LiteLLM v1.104.0 (https://github.com/BerriAI/litellm/issues/45504), a wildcard deployment model_name tinker/* with litellm_params.model openai/* and a custom api_base pointing at the Tinker OpenAI-compatible endpoint (no API key) causes GET /v1/models and /model/info to expand the local OpenAI catalog under the tinker/ prefix. This advertises IDs the endpoint does not serve, for example tinker/gpt-6-luna, and requests to them reportedly fail with the message "Sampling is not supported". Source: issue body. Reported context: the reporter says the Tinker /models endpoint can return an empty checkpoint list even though base models are callable, and that current supported IDs are published in Tinker's docs JSON files. The expected behavior stated is endpoint-aware or provider-specific discovery, or an explicit discovery catalog override, and never advertising the unrelated OpenAI catalog. The reporter also asks that upstream org namespaces such as openai/gpt-oss-120b be preserved when a custom wildcard prefix is added. Source: issue body. Cause status: a commenter (author association NONE, not a maintainer) states that get_provider_models in litellm/proxy/auth/model_checks.py returns the local OpenAI catalog for a known provider and ignores api_base. This is a hypothesis; no maintainer confirmation or code verification appears in the supplied content. Source: issue comment https://github.com/BerriAI/litellm/issues/45504#issuecomment-6077668597. Fix status: the same commenter says they have a fix branch that discovers the live catalog from the configured endpoint and advertises nothing if it is unreachable, and that a PR is incoming. No PR, merge or release link is supplied, so this is neither a confirmed fix nor a shipped release. Source: same comment. Limitations: this is an external report and was not reproduced by KFA. The live endpoint behavior was not rerun. No workaround is stated. The issue is open with no maintainer response in the supplied content, and comment coverage may omit middle comments. Practical diagnosis supported so far: if a custom-api_base openai/* wildcard lists model IDs that the upstream does not serve, compare the listed IDs with the upstream's documented supported models. Treat this as a reported discovery problem rather than a confirmed upstream cause.