research: evaluate capacity-aware cascade admission below semantic routing

Motivation

Evaluate whether an ordered strong-model/fallback cascade improves quality/SLO behavior when the preferred model's serving pool is saturated.

The repository decision record in #2513/#2514 is binding: semantic routing stays per-query; real-time capacity, queues, spillover, and admission are handled by the serving/LB layer below semantic routing.

Audited upstream baseline (2026-07-15)

• The semantic router emits a preferred logical model. Current main does not expose a first-class ordered logical-model fallback contract; upstream-error fallback remains open in #2294.
• FleetSim includes least-loaded/spillover routing primitives and capacity models.
• Current main does not provide a production contract that joins a semantic fallback order with live pool headroom and downstream acknowledgements.
• Matched-cost experiments in the decision record found little and unstable headroom for putting capacity optimization inside semantic routing.

Research scope

1. First define and validate a versioned fallback contract with #2294: preferred model, ordered eligible logical-model fallbacks, quality/safety constraints, SLO class, and expiry. Until then, evaluate only same-model endpoint/pool admission and spillover.
2. Let the LB/admission layer combine that contract with live concurrency, queue, health, and capacity.
3. Evaluate policies such as wait, spill to another replica/region, use an allowed fallback, or reject/defer.
4. Reproduce matched-cost and matched-SLO baselines in FleetSim; include adversarial bursts and prediction error.
5. Record router preference, LB observation, admission action, and outcome as separate events.
6. Roll out only as simulation/shadow recommendations until a downstream owner and rollback contract exist.

Architectural boundary

• No batch/capacity solver in the ext_proc hot path or semantic model-selection algorithm.
• Capacity cannot introduce another logical model unless a validated fallback contract from #2294 explicitly permits it; otherwise it may choose only compatible endpoints for the preferred model.
• Safety, authorization, residency, and context compatibility are hard constraints.
• Any proposal to let live capacity alter semantic candidate generation requires reopening #2513 with new evidence.

Acceptance criteria

• The router/LB ownership boundary and fallback semantics are explicit.
• Simulation compares per-query + ordinary LB baselines at matched cost/SLO.
• Queue/headroom telemetry freshness and uncertainty are modeled.
• Missing/stale capacity data has a safe deterministic fallback.
• LB action is idempotent, observable, and reversible.
• Replay distinguishes recommendation from actual admission/spillover.
• Results state when the policy has no material benefit.

Likely change surfaces

src/fleet-sim/fleet_sim/routing/, src/fleet-sim/fleet_sim/optimizer/, src/fleet-sim/fleet_sim/core/, deployment LB/GIE integration, router response metadata/replay, docs, and tests.

Related: #2294, #2332, #2359, #2513, #2551.

Validation entrypoint

make agent-report ENV=cpu CHANGED_FILES="<space-separated changed files>"

Follow the reported gates and affected E2E profiles.