feature: per-alias reasoning_effort for backward-compatible model migration

Problem

As the ecosystem moves to reasoning-first models (DeepSeek-R1, Qwen3, etc.), we at Siemens need to retire older models while keeping client API calls unchanged. Simply remapping an alias to a reasoning model forces chain-of-thought on every request, including ones where it is undesired, with no way to control it at the router level. Mainly we need a way to force reasoning_effort=none so we can swap in a reasoning model as a drop-in replacement without changing client behaviour.

It would also enable creating dedicated aliases for capability tiers (fast, thorough, etc.) from a single engine deployment.

What we'd want is something like:

# CLI / JSON
gpt-4o:qwen3-32b|reasoning_effort=none
gpt-4o-mini:qwen3-32b|reasoning_effort=low
gpt-4o-thorough:qwen3-32b|reasoning_effort=high

# YAML
static_aliases:
  gpt-4o:
    model: qwen3-32b
    reasoning_effort: none

The router injects reasoning_effort into the forwarded request when the client hasn't set it (client value always wins). Plain alias:model aliases stay unchanged, fully backward-compatible.

Start at the router's CLI/JSON alias syntax and the static_aliases YAML entry point described in the issue. Trace how aliases become forwarded requests and how client-supplied parameters are handled. Done means per-alias reasoning_effort is injected only when absent, client values win, and plain alias:model behavior remains unchanged.