model-gateway: derive pin-alias names from the deployed GGUFs

[AlienWalker1995]

Problem

The gateway's pickable pin aliases were hardcoded model-generation names (qwen3.6-27b, qwen3.6-35b-a3b-cpu). After an active-model swap the gateway kept advertising an alias named for the previous generation (observed live: qwen3.6-27b serving Qwen3.8 weights). The GPU entries' supports_vision flag and the served_by build name had the same hardcoded-drift problem.

Fix — make the model list deployment-derived

Uses the same .env-driven entrypoint templating the model_info values already use, so alias names can no more drift than weights_file can:

• __GPU_MODEL_NAME__ / __CPU_MODEL_NAME__ derived from LLAMACPP_MODEL / LLAMACPP_CPU_MODEL basenames (lowercased, .gguf stripped, CPU suffixed -cpu). A model swap + gateway recreate renames the aliases automatically.
• router_settings.fallbacks targets the templated CPU alias — the failover contract can never name an undeclared model; test_the_failover_router_is_configured_to_route_there still verifies this placeholder-to-placeholder on the raw template.
• __GPU_SUPPORTS_VISION__ = true iff LLAMACPP_MMPROJ is non-empty.
• __GPU_IMAGE__ — served_by reports the actual LLAMACPP_IMAGE instead of a hardcoded build name.
• Model-family prose replaced with weights_file references; README documents the derived names and that only local-chat/local-embed are stable ids.

local-chat and local-embed are unchanged by contract. Repo grep found no consumers of the old version-named aliases outside the gateway's own files.

Validation

• ruff check . clean; tests/substrate/test_gpu_arbitration.py 23/23.
• Template render simulated with production env values → YAML parses, fallback target ∈ declared names, vision flags are real booleans.
• Deployed live: /v1/models now advertises qwen3.8-27b-q6_k + qwen3.6-35b-a3b-ud-q4_k_m-cpu; completions succeed through both local-chat and the derived pin alias.

🤖 Generated with Claude Code