docs(guide): document API Route configuration

[DennyHo0917]

Summary

Document API Route as an example for the existing openai_compatible backend. I maintain API Route.

This is an 18-line documentation change in docs/guide/new-backend.md; no backend, dependency, default, routing, or configuration code changes.

Configuration detail addressed

The gateway accepts bare IDs such as gpt-6.1-sol and claude-fable-5-1 through Chat Completions. Copying a namespaced gateway example or inferring an Anthropic backend from the model name would select the wrong route. Its authenticated catalog is scoped to the key's group and permissions, so a model listed on the public pricing page is not necessarily available to a particular key.

The example links the provider API documentation, shows the shared connection variables, and reminds script users to select both role backends separately. It adds no pricing, growth, benchmark, or capability claims, following the maintainer's guidance in #297.

Verification

• python -m mkdocs build --strict: passed.
• python -m pytest tests/test_openai_compatible_backend.py tests/test_openai_compatible_config.py -q: 21 passed.
• PYTHONUTF8=1 PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 python -m pytest tests/ -q: 1,639 passed, 86 skipped, 6 failed, 354 subtests passed on Windows. The identical six failures reproduce on untouched upstream 343db229dbd5ddaf9df6b1d5540d8bcdb2604d5c (one home-directory scope assertion and five sleep-engine subcases). No full-suite pass is claimed locally; Linux PR CI is pending.
• git diff --check: passed.
• Endpoint and example IDs were verified against the authenticated API Route catalog on 2026-10-07. No SkillOpt paid integration run or training-performance claim is made.

Rollback

Revert the documentation change. Existing runtime behavior is unchanged.

Current head: the Microsoft license/CLA check passed. PR CI is action_required, awaiting maintainer approval; no Linux CI pass is claimed.

[Yifan Yang (Yif-Yang)]

Thank you for documenting the setup and clearly stating the verification limits. I do not plan to add this provider-specific entry: the current guide already covers bare model IDs, OpenAI-compatible gateways serving different upstream model families, shared connection variables, and explicit backend/model settings for both roles. The key-visible catalog advice is useful general guidance, but this change does not establish a distinct SkillOpt configuration or interoperability need.

One configuration detail from local verification: training and evaluation scripts need the intended model.optimizer and model.target values as well as the role backend fields; the environment-variable section already shows both. The generic backend remains available for this provider without a dedicated entry.