Multi-provider selection, switch, and end-to-end validation

[Ryan-Atkinson87]

Capstone: wire provider selection into the engine and prove the full wave loop end-to-end on a second provider. Per §3.3 the orchestrator must not require all three providers to exist — Claude-only runs must keep working unchanged.

Spec §3.3 (build order — prove the loop on a provider; engine must not require all three), §3.4 (run-start instruction-file generation), §6.8 (provider/plan switching), §16.3 (provider.models).

Acceptance criteria

• The engine selects the adapter from the configured provider (project.yaml provider, §16.3, or the run-control selection); defaults to Claude; absence of Codex/Gemini config does not break Claude runs (§3.3).
• At run start the correct instruction file is generated per provider — CLAUDE.md + skills for Claude, AGENTS.md for Codex/Gemini — via Provider-format renderer (compose personas to CLAUDE.md + skill files) #22/AGENTS.md instruction-file renderer for Codex/Gemini #69 (§3.4).
• Per-role model resolution uses the selected provider's provider.models mapping (§16.3); no provider-specific model logic outside config + adapter.
• Non-Claude UsageReports from each session feed the meter model and governing-meter selection (Usage meter model, governing-meter selection, and reader interface #30); usage gauges reflect the active provider.
• A provider/plan switch reloads the correct meters mid-run (§6.8) via Provider/plan switch meter reload and wave-loop monitor integration #37.
• A full wave (plan → implement → gate → internal review → hand-off PR) runs end-to-end on at least one non-Claude provider, exercised on Trive (§3.3).
• No provider-specific logic outside the adapter implementations (§3.3 boundary rule).

Depends on: #69, #71, #73, #30, #29, #37