research: integrations outcome + rich wizard cards + coordinator template

Adds a fifth outcome kind ('integrations') tuned for the "audit repo,
survey papers, propose a menu of concrete integrations" use case.
Every INT-XX item is self-contained (what, how, where, prereqs, effort,
risk, testing, rollback, acceptance) so a downstream loop can execute
one per iteration.

Backend:
- Migration 0041 drops + re-adds the outcome_kind CHECK constraint
  with 'integrations' allowed. Existing rows unaffected.
- VALID_OUTCOMES gains 'integrations'.
- New deliverable_template(kind) returns the canonical section shape
  for each outcome — spec, prod_plan, roadmap, paper, integrations all
  get first-class treatment (prior: all shared a bare label).
- build_coordinator_task injects an ARTIFACT SHAPE block from the
  template into the coordinator prompt, so the final synthesis
  actually matches the promise the wizard made.

Frontend:
- OutcomeKind gains 'integrations'.
- ResearchWizard OUTCOMES list carries a `sections` array per kind.
- Selected card renders an "ARTIFACT WILL CONTAIN" preview so users
  pick by seeing what they'll get, not by reading a one-line hint.
- Integrations card gets the fullest preview (executive summary +
  INT-XX card shape) since it's the most structured deliverable.

Follow-ups queued (next commit): loop wizard "Import from research
artifact" bridge + one-INT-per-iteration mode.

crates/cm-api/src/routes/research.rs

@@ -28,7 +28,91 @@ use uuid::Uuid;
 
 use crate::{ApiError, AppState, Authed};
 
-const VALID_OUTCOMES: &[&str] = &["spec", "prod_plan", "roadmap", "paper"];
+const VALID_OUTCOMES: &[&str] = &["spec", "prod_plan", "roadmap", "paper", "integrations"];
+
+/// The canonical deliverable shape for an outcome kind, injected into the
+/// coordinator prompt so runs actually produce the promised structure —
+/// prior to this the kind was a bare label with no template. The block
+/// lands under an "ARTIFACT SHAPE" header in the coordinator task.
+fn deliverable_template(kind: &str) -> &'static str {
+    match kind {
+        "spec" => {
+            "\
+Deliver a technical specification with exactly these sections in order:\n\
+  ## Problem\n\
+  ## Goals + non-goals\n\
+  ## Interfaces (types, function signatures, protocols)\n\
+  ## Data model\n\
+  ## Alternatives considered (with rejection rationale)\n\
+  ## Acceptance criteria (measurable)\n"
+        }
+        "prod_plan" => {
+            "\
+Deliver a prioritized execution plan with exactly these sections in order:\n\
+  ## Objective\n\
+  ## Success metrics\n\
+  ## Workstreams (P0 → P1 → P2, each with owner + estimate)\n\
+  ## Milestones (dated where possible)\n\
+  ## Risks + dependencies\n\
+  ## Definition of done\n"
+        }
+        "roadmap" => {
+            "\
+Deliver a horizon roadmap with exactly these sections in order:\n\
+  ## Vision\n\
+  ## Now (0-6 weeks) — bulleted, dated\n\
+  ## Next (6-16 weeks) — themes + expected outputs\n\
+  ## Later (16+ weeks) — bets + open questions\n\
+  ## Cross-cutting concerns\n"
+        }
+        "paper" => {
+            "\
+Deliver a short scientific-style paper with exactly these sections in order:\n\
+  ## Abstract (150-200 words)\n\
+  ## Background + related work (with citations)\n\
+  ## Method\n\
+  ## Findings\n\
+  ## Discussion + limitations\n\
+  ## References\n"
+        }
+        "integrations" => {
+            "\
+Deliver a prioritized MENU of concrete integrations we can implement in the \
+BOUND REPO, each grounded in one or more published papers AND in real files/\
+modules of this repo. Every integration is self-contained so a downstream \
+coding loop can execute exactly one item per iteration.\n\
+\n\
+Required top matter:\n\
+  # Integration Plan · <repo slug>\n\
+  ## Executive summary\n\
+  · Focus areas: <perf | stability | security | provenance — one or more>\n\
+  · Papers surveyed: <n>\n\
+  · Recommended integrations: <n> (P0: <n>, P1: <n>, P2: <n>)\n\
+\n\
+Then ## Integrations, and for EACH candidate emit an item with this exact \
+shape and stable id (INT-01, INT-02, ...) so a loop can address items by id:\n\
+\n\
+  ### INT-<NN>  ·  <Name>  ·  P0|P1|P2  ·  <focus area>\n\
+  **What it is**: 1-3 sentence description of the technique.\n\
+  **Source(s)**: paper title · authors · year · arXiv/DOI (one line per paper).\n\
+  **How we would accomplish it**: numbered concrete steps — reference the \
+  paper's algorithm/section AND the repo's actual file paths.\n\
+  **Where in the architecture**: bulleted list of files/modules touched; \
+  mark NEW modules explicitly.\n\
+  **Prerequisites**: other INT-ids that must land first (or 'none').\n\
+  **Effort**: S / M / L with a one-line breakdown.\n\
+  **Risk**: low / med / high + one specific concern.\n\
+  **Testing**: existing suites to exercise + new tests to add.\n\
+  **Rollback**: feature flag name or revert plan.\n\
+  **Acceptance criteria**: bulleted, measurable, tied to the focus area.\n\
+\n\
+Ordering rules: sort by priority (P0 first), and within a priority sort so \
+prerequisites come before dependents. Cite every claim with either a paper \
+reference or a repo file path — never fabricate paths or citations.\n"
+        }
+        _ => "",
+    }
+}
 
 fn check_outcome(kind: &str) -> Result<(), ApiError> {
     if VALID_OUTCOMES.contains(&kind) {
@@ -124,12 +208,19 @@ fn build_coordinator_task(
     } else {
         ""
     };
+    let template = deliverable_template(outcome);
+    let shape_block = if template.is_empty() {
+        String::new()
+    } else {
+        format!("ARTIFACT SHAPE (the final synthesis MUST match this):\n{template}\n")
+    };
     let framing = format!(
         "RESEARCH TOPIC: {title}\n\
-         OUTCOME KIND: {outcome} (spec / prod_plan / roadmap / paper)\n\n\
+         OUTCOME KIND: {outcome} (spec / prod_plan / roadmap / paper / integrations)\n\n\
          DESCRIPTION:\n{description}\n\n\
          {repo_block}\
          {repo_guidance}\
+         {shape_block}\
          TEAM:\n{roster}\n\n"
     );
     let body = match topo {