Make the resolved Mastra model runtime the sole invocation seam

[justsml]

Problem

The recently added resolved Mastra model runtime improves coherence, but product and eval callers can still obtain the model URI, chat model, generation settings, provider options, and provenance through separate paths. Those paths resolve and parse independently and intentionally differ around explicit URI options and local fallback. A caller can therefore assemble an incoherent candidate or ancillary runtime.

Provider construction, OpenAI-compatible transport adaptation, Qwen prompt compatibility, tuned defaults, reasoning projection, and provenance also remain mixed in src/mastra/config/model.ts.

What to build

Make the resolved Mastra model runtime the sole module through which candidate and ancillary invocations obtain their effective URI, model, settings, provider options, and provenance. Keep provider construction and transport compatibility behind real provider adapters; the repository already has multiple providers, so this is an established seam.

Acceptance criteria

• Candidate, title, memory, observation/reflection, completion-review, command-judge, and eval invocations obtain one coherent resolved runtime rather than assembling model/options/provenance separately.
• Effective invocation identity and recorded provenance cannot disagree after fallback, endpoint selection, reasoning mapping, or tuned-default application.
• Explicit user/model URI settings remain distinguishable from effective fallback without silently changing either.
• Provider-specific construction and transport behavior are local to provider adapters and do not leak into ordinary callers.
• llm-strings remains the only URI parsing, building, normalization, and provider-option mapping path.
• Test injection through setMastraChatModelFactoryForTests remains supported.
• Integration coverage observes coherent invocation plus provenance for representative native, OpenRouter, and local OpenAI-compatible routes.
• Existing callers that require a different ancillary model do so through an explicit resolved runtime, not implicit environment fallback.

Architecture evidence

The 2026-08-30 architecture review found high leverage under the deletion test: deleting the current model module would spread fallback, provider construction, compatibility adaptation, and reasoning mapping across every caller. The repair should shrink its public interface, not scatter pure helpers for testability.