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/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.