Module model_roster 

Cohesive model/provider value object shared by the request/spawn param structs.

Historically the per-request model selection was a “data clump” of ~8 loose fields (model, provider_name, provider_type, plus three auxiliary role pairs <role>_model + <role>_model_provider) repeated verbatim across ExecuteRequest, ExecuteRequestBuilder, SessionExecutionArgs, and the server’s ResolvedRunConfig / SpawnAgentExecution. ModelRoster collapses that clump into one value object so the param structs carry a single cohesive field.

Lives in bamboo-engine

RoleModel::provider_override is an Arc<dyn LLMProvider>, and LLMProvider lives in bamboo-infrastructure. bamboo-domain does not depend on bamboo-infrastructure, so hosting the roster there would force a new runtime dependency just to carry a live provider handle. bamboo-engine already depends on infrastructure (and is depended on by the server), making it the natural home for a value object that carries live provider handles.

Resolution semantics are preserved byte-for-byte

The roster carries intent only; it performs no Config fallback itself. A None auxiliary role maps exactly to the old “both name and provider were None” state, so the downstream None → Config::get_* fallbacks in AgentRuntime::execute are unchanged. The primary model/provider_name/provider_type keep the same request→config cascade at their resolution sites.

Structs

ModelRoster

Cohesive value object for a request’s primary + auxiliary model selection.

RoleModel

A single auxiliary role’s model selection: an optional model name plus an optional dedicated provider handle.