feat(gateway): show configured OpenRouter routing after model switch

[will-lynas]

What does this PR do?

When a gateway /model switch selects an OpenRouter model, the confirmation currently shows the model and the OpenRouter aggregator but hides the configured downstream routing that will govern the next request.

For example:

model:
  aliases:
    glm53: openrouter/z-ai/glm-5.3:exacto

provider_routing:
  models:
    "z-ai/glm-5.3:exacto":
      only: [fireworks]
      data_collection: deny

Before

Model switched to `z-ai/glm-5.3:exacto`
Provider: OpenRouter
_(session only — add `--global` to persist)_

This is misleading because z-ai is the model publisher namespace, not the configured inference host, while the Fireworks-only route is invisible.

After

Model switched to `z-ai/glm-5.3:exacto`
Provider: OpenRouter
provider_routing: {"only":["fireworks"],"data_collection":"deny"}
_(session only — add `--global` to persist)_

The added line is deliberately labelled as configuration. It reuses the request path's validation and per-model override resolution; it does not capture or claim which downstream provider actually served a response.

Related Issue

Fixes #110784

Overlaps #110789, which also changes the CLI confirmation; this PR is limited to gateway /model confirmations.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• gateway/slash_commands_model.py
  • render the validated effective provider_routing object for OpenRouter routes
  • use the gateway's startup snapshot for flat routing settings and the same live per-model resolver as request construction
  • normalize supported values through the existing request-path helper
  • fail open for absent, invalid, or non-serializable routing values
• tests/gateway/test_model_switch_provider_routing_display.py
  • exercise the real gateway /model command against a temporary profile config
  • prove per-model values overlay the gateway's flat routing snapshot
  • cover normalization and malformed-value fail-open behavior

How to Test

1. Add the example glm53 alias and Fireworks routing rule above to config.yaml.

2. Run /model glm53 through a messaging gateway.

3. Confirm the response includes provider_routing: {"only":["fireworks"],"data_collection":"deny"} and does not claim that Fireworks served a request.

4. Run:

   scripts/run_tests.sh tests/gateway/test_model_switch_provider_routing_display.py tests/gateway/test_model_command_*.py tests/gateway/test_model_switch_*.py tests/gateway/test_session_model_override_routing.py tests/agent/test_per_model_provider_routing.py

   Local result: 28 passed across 13 files. Ruff and git diff --check also pass.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate — overlapping feat(model): show effective OpenRouter provider pins on switch #110789 is noted above
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass — affected suites pass; the full gateway suite has one unrelated test_readiness.py failure
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 26.6.2, Python 3.11

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A: no setup or configuration semantics changed
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A: no config keys changed
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A: no architecture or workflow changes
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — platform-independent confirmation formatting only
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A: no model-facing tool behavior changed

Screenshots / Logs

Focused model-switch and routing suites:
=== Summary: 13 files, 28 tests passed, 0 failed ===

Full gateway suite:
8,643 passed, 43 skipped, 1 unrelated failure in tests/gateway/test_readiness.py

Independent exact-head re-review:
No remaining blocking or important findings.

[alt-glitch]

This was generated by AI during triage.

Related: #110789 (opened earlier) implements the same feature request #110784 across both the gateway /model command and the CLI/TUI switch path; this PR covers the gateway confirmation only. Flagging the overlap so a maintainer can pick one.