feat(missions): Slice 5 — let a model size the mission's team

`routes/planner.rs` has had Opus proposing rosters since the Master Planner
shipped, and none of it ever reached a mission: the proposal lived in React state
and died with the tab. A mission's shape came from a team template instead —
fixed roles, and every claw minted `claude-sonnet-5` from a literal in
`mint_team_from_template`. That literal is why no mission has ever run more than
one provider.

A roster is `(topology_kind, [(role, backend)])`, which is exactly what the
composed executor already consumes: `Roster::graph` builds a `TopologyGraph` with
the backend in `attrs`, and `MicroVmTurnExecutor` reads `attrs["backend"]` per
node. So a verifier on another provider's rootfs stops being a bolt-on and
becomes a graph node — the correlated-failure break the independent judge exists
for, one layer down.

Three verbs, and the split is the point. **suggest** asks the model and persists
the answer, changing nothing. **decide** approves (writes `config.roster` and
switches the mission to the composed engine) or rejects. A proposal is never
applied on arrival: a model sizing a team is a suggestion about how many VMs to
boot, and this codebase treats model output that costs money as evidence for a
decision, not the decision.

Fail-closed at every seam, because each of these otherwise surfaces much later
and much more expensively:

  - a backend no ONLINE node can boot is refused when PROPOSED, naming the ones
    the fleet actually has. Placement would refuse it too — at launch, after the
    roster was approved and someone believed the mission would run. The model is
    handed that same list in its prompt, so the usual case never arises.
  - an invented `topology_kind` is refused, not defaulted. `parse_topology_kind`
    defaults to hub-spoke, which is right for a template we wrote and wrong for a
    string a model just produced: running a `pipeline` proposal as a hub-and-spoke
    changes what every node sees and nothing would say so.
  - the roster is validated BEFORE it is stored, so a stored proposal is always
    one that could be approved; and again at approval, against the fleet as it is
    then — a node can go offline in between.
  - `MAX_MEMBERS = 6`. Each member is a whole VM, not a subagent, and a model
    asked to size a team proposes twelve happily.

Two properties live in SQL rather than in the handler: at most one approved
roster per mission (partial unique index — two approved rosters are two answers
to "what shape is this mission", and the executor reads one field), and
decide-once (`WHERE status = 'proposed'`, so a double-clicked approve claims
nothing the second time). Both tested against a real database, including that the
second approval is refused by Postgres rather than merely losing a race.

NEGATIVE CONTROL, run rather than assumed: with the roster preference removed
from `composed_graph`, `an_approved_roster_outranks_the_template` FAILS — 3 nodes
from the template instead of the roster's 2. A stored roster that is silently
ignored at launch is precisely the shape this project keeps paying for.

Not closed: per-role models for CLAWS. `template_roles` has no model column, so a
ZeroClaw team still mints one model for every role. The literal is now a named
constant that says so and points at the roster path, rather than sitting inline
where nobody reads it.

527 tests pass, clippy clean. Migration 0070. Not yet exercised against the
deployed stack — the route has never been called with a live model.

Co-Authored-By: Claude Opus 5 <[email protected]>

crates/cm-api/tests/mission_orchestrator.rs

@@ -258,3 +258,68 @@ async fn on_launch_no_template_hard_fails() {
         .unwrap();
     assert!(team_id.is_none());
 }
+
+/// Slice 5: an APPROVED roster outranks the team template.
+///
+/// The template gives every composed mission the same five roles on the same
+/// image. A roster is the model's answer for THIS mission, and it is the only
+/// path that carries a per-node backend — which is how a mission runs more than
+/// one provider at all. If the template won, a heterogeneous roster would be
+/// accepted, stored, and then silently ignored at launch.
+#[tokio::test]
+async fn an_approved_roster_outranks_the_template() {
+    let pool = cm_testkit::test_pool().await;
+    let ws = seed_workspace(&pool).await;
+    let template_id = seed_test_template(&pool).await;
+    let mission = seed_mission(&pool, ws, template_id, "roster beats template").await;
+
+    // With no roster, the shape comes from the template — the behaviour every
+    // composed mission had before this slice.
+    let from_template = mission_orchestrator::composed_graph(&pool, mission, &["mission"])
+        .await
+        .expect("template graph")
+        .expect("the template supplies a shape");
+    let template_nodes = from_template["nodes"].as_array().unwrap().len();
+    assert!(template_nodes >= 1);
+    assert!(
+        from_template["nodes"][0]["attrs"].get("backend").is_none(),
+        "a template cannot express a per-node backend — that is the gap the roster fills"
+    );
+
+    // Approve a roster the way the route does: the built graph under
+    // `config.roster`.
+    let roster = cm_api::mission_roster::Roster {
+        topology_kind: "pipeline".into(),
+        members: vec![
+            cm_api::mission_roster::RosterMember {
+                role: "implementer".into(),
+                backend: Some("claude".into()),
+                rationale: None,
+            },
+            cm_api::mission_roster::RosterMember {
+                role: "verifier".into(),
+                backend: Some("kimi".into()),
+                rationale: None,
+            },
+        ],
+    };
+    let graph = roster.graph().expect("a runnable graph");
+    sqlx::query(
+        "UPDATE missions SET config = jsonb_set(config, '{roster}', $2::jsonb, true) WHERE id = $1",
+    )
+    .bind(mission)
+    .bind(&graph)
+    .execute(&pool)
+    .await
+    .unwrap();
+
+    let chosen = mission_orchestrator::composed_graph(&pool, mission, &["mission"])
+        .await
+        .expect("roster graph")
+        .expect("the roster supplies a shape");
+    let nodes = chosen["nodes"].as_array().unwrap();
+    assert_eq!(nodes.len(), 2, "the roster's two nodes, not the template's");
+    assert_eq!(nodes[0]["role"], "implementer");
+    assert_eq!(nodes[0]["attrs"]["backend"], "claude");
+    assert_eq!(nodes[1]["attrs"]["backend"], "kimi");
+}