feat(lanes): add pipeline-template picker to the Workspace lane header

Lets a lane's pipeline template be switched live from the dashboard
(the same PATCH /api/lanes/:id the CLI's `ccam lanes pipeline` uses),
so lanes created before the picker shipped don't need the terminal.
Both ship-feature skills now force their own template before their
first `ccam stage` call, so the human never has to pick correctly at
lane creation.

docs/LANES.md

@@ -420,16 +420,20 @@ The dashboard web UI shows each lane as a card in a grid, with the selected lane
 
 A lane moves through stages defined in a **pipeline template** (see "Custom pipeline templates" below). The default pipeline has eight stages: `intake`, `plan`, `implement`, `tests`, `review`, `gate`, `ship`, and `done`.
 
-**A lane is created on `default` unless told otherwise.** The "+ Add lane" modal has a *Pipeline template* select listing every template the server reports, so this is chosen at creation; `ccam lanes add --pipeline <id>` is the same choice from the terminal. Creation is the point that matters — a lane born on `default` renders 8 nodes for a 16-node workflow.
+**A lane is created on `default` unless told otherwise.** The "+ Add lane" modal has a *Pipeline template* select listing every template the server reports, so this is chosen at creation; `ccam lanes add --pipeline <id>` is the same choice from the terminal.
 
-For a lane that already exists (including every lane created before the picker shipped):
+For a lane that already exists, switch it from the terminal:
 
 ```bash
 ccam lanes pipeline                 # which template this lane uses, and what else exists
 ccam lanes pipeline ship-feature    # switch it
 ```
 
-Switching re-resolves the lane's existing declared `stage` against the new node list. A stage the old template knew may resolve to nothing in the new one; the command warns when that happens, and the next `ccam stage` fixes it.
+or from the dashboard: the pipeline-template select next to the lane's title in the Workspace detail panel does the same `PATCH /api/lanes/:id` the CLI uses, live (disabled while viewing an archived feature snapshot).
+
+Switching re-resolves the lane's existing declared `stage` against the new node list. A stage the old template knew may resolve to nothing in the new one; the switch warns when that happens (both CLI and UI), and the next `ccam stage` fixes it.
+
+**In practice you never have to pick correctly at creation.** The template only has to match whichever skill is actually driving the lane, and the skill enforces that itself: `ship-feature-lane` runs `ccam lanes pipeline ship-feature` and `ship-feature` runs `ccam lanes pipeline default` before their first `ccam stage` call — a no-op if the lane is already on that template, a self-correction if it isn't. A human chatting with the lane never needs to open the picker; whichever skill gets invoked decides the template.
 
 The dashboard renders every node in the pipeline in one of five **states**:
 
@@ -452,7 +456,9 @@ In both cases, the stage is not **done** — it's incomplete or untested. Amber
 
 ## Reporting a stage
 
-When a skill reaches a significant milestone, it reports the current stage to the dashboard using `ccam stage`:
+`ccam stage` is not skill-only. Any Claude session working inside an adopted lane's cwd — including a plain chat session where no skill was ever invoked — should call it on real stage transitions. Tool-event detection (see "Inferred vs. declared" below) can only paint the amber "detected" badge; it never moves the blue `current` ring. A lane worked entirely through plain chat that never calls `ccam stage` will keep showing whatever stage it was last declared at (often `intake`), regardless of how much real work happens.
+
+When a skill — or a plain chat session — reaches a significant milestone, it reports the current stage to the dashboard using `ccam stage`:
 
 ```bash
 ccam stage implement --evidence "Schema created, migrations run"