feat(workflows): pick a lane in the pipeline pass-rate panel

The panel aggregated every lane at once, which answers "does this stage get
proved across the project" but never "does THIS lane prove it". A lane picker
now narrows the same aggregation through ?lane=<id> on
GET /api/lanes/pipeline-stats, counting that lane plus its own archived
features — dropping the features would hide most of a lane's history the moment
it starts its next one.

The response carries a `lanes` array that the filter never narrows: it
populates the picker, so it has to keep offering every other lane even while
the counts show one. For the same reason the picker renders above the empty
branch rather than inside the populated one — narrowing to a lane that has
recorded nothing would otherwise be a one-way trip, with no control left to
select anything else. A lane filter that is not a positive integer is rejected
with 400 EBADLANE rather than silently aggregating everything.

docs/API.md

@@ -576,7 +576,11 @@ GET /api/lanes/pipeline-stats
 How often each pipeline node was actually passed, aggregated over every lane
 **and** every archived feature (an archived feature is a finished run of a
 pipeline, so it carries most of the history once a lane starts its next
-feature). No parameters; grouped by pipeline template, busiest first.
+feature). Grouped by pipeline template, busiest first.
+
+**Query parameters:**
+- **`lane`** — lane id; narrows the aggregation to that lane and its own
+  archived features. Omit (or pass `all`) for every lane.
 
 ```json
 {
@@ -590,10 +594,13 @@ feature). No parameters; grouped by pipeline template, busiest first.
           "entered": 4, "passed": 4, "withEvidence": 4, "failed": 0 }
       ]
     }
-  ]
+  ],
+  "lanes": [{ "id": 1, "title": "api lane", "cwd": "/w/api" }]
 }
 ```
 
+- **`lanes`** — every lane, for the picker. Never narrowed by `lane`, so the
+  response always offers the way back to the other lanes.
 - **`runs`** — lanes plus archived features recorded against this template.
 - **`entered`** — stage records that resolve onto this node (aliases included).
 - **`failed`** — records whose `result` is `"fail"`; **`passed`** is the rest,
@@ -602,8 +609,10 @@ feature). No parameters; grouped by pipeline template, busiest first.
   from `passed` because a claim and a proof are not the same fact — the same
   distinction the pipeline map draws between `done` and `passed-no-evidence`.
 
-**Status codes:** **200** always (an empty `pipelines` array when no lane has
-recorded a stage yet).
+**Status codes:**
+- **200** — success (an empty `pipelines` array when no lane has recorded a
+  stage yet, or when `lane` names an id that no longer exists)
+- **400** `{ "error": { "code": "EBADLANE", "message": "lane must be an id" } }` — `lane` is not a positive integer
 
 ### Workflows
 

docs/LANES.md

@@ -482,6 +482,11 @@ feature, so without them the history would reset every time a lane starts new
 work. The Workflows page renders this as one bar per node (see
 `client/src/components/workflows/LanePipelinePanel.tsx`).
 
+`?lane=<id>` narrows the same aggregation to one lane and its own archived
+features, which is what the panel's lane picker sends. The `lanes` array in the
+response is never narrowed — it populates that picker, so it has to keep
+offering every other lane even while the counts show only one.
+
 ## Attaching a real terminal to a lane
 
 `ccam lanes shell` attaches a real terminal to the exact tmux session the dashboard's Start/Resume buttons use for this lane (`ccam-lane-<id>`), creating it if it doesn't exist yet. Type `claude` inside it like any normal terminal session — the dashboard's Workspace terminal view is just another client attached to the same tmux session, so both stay in sync live.