docs: clarify provider-specific routing for aliased models

[RaviTharuma]

Summary

• document when to prefer /api/provider/{provider}/... over the merged /v1/... endpoints
• explain that aliases and fallback pools can make the merged model view ambiguous across providers
• add the same routing note to the Chinese and Japanese READMEs
• add a matching warning to config.example.yaml near oauth-model-alias

Why

In a real multi-provider setup, the merged /v1/models inventory can reflect alias-renamed or pooled model names rather than the backend a client is trying to force. The provider-specific request paths are the reliable way to select an executor family when routing needs to stay deterministic.

Concrete examples from a live setup:

• POST /api/provider/anthropic/v1/messages returned Anthropic headers for a Claude request
• POST /api/provider/google/v1beta/models/...:generateContent returned Google/Gemini headers for a Gemini request
• the merged /v1/models view remained alias-oriented, which is why the docs now call out the distinction

[gemini-code-assist]

Code Review

This pull request updates the documentation in README.md, README_CN.md, README_JA.md, and config.example.yaml to advise users on using provider-specific API paths for deterministic routing. These additions clarify that provider-specific endpoints should be preferred over merged OpenAI-compatible endpoints when model aliases or fallback mappings create ambiguity in backend selection. I have no feedback to provide as there were no review comments.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d54de441d3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[RaviTharuma]

Updated the docs section in commit 224f0de. The provider-specific routing examples now use neutral {provider} placeholders and generic protocol shapes instead of named providers.

[luispater]

Summary

This PR updates documentation only (README EN/CN/JA and config.example.yaml) to clarify how /api/provider/{provider}/... routes should be interpreted versus merged /v1/... routes.

Key findings

• No blocking issues found.
• The final wording is consistent with current implementation behavior: provider-specific paths select protocol surface, while inference backend resolution still follows model/alias resolution.
• The warning added near oauth-model-alias in config.example.yaml matches the runtime routing behavior and helps prevent operator misunderstanding.

Test plan

• Not applicable (docs-only PR).

This is an automated Codex review result and still requires manual verification by a human reviewer.