feat(workflows): pipeline pass rates and skill/plugin usage

Restores the five analytics sections that turned out to be worth keeping
(patterns, model delegation, error propagation, session complexity, compaction
impact) and reworks what the page opens on.

The lane panel no longer mirrors the Workspace's live lane strip. It now
answers the question the strip cannot: how often each pipeline node actually
passes. GET /api/lanes/pipeline-stats aggregates every stage record of every
lane AND every archived feature — a lane's own `stages` only holds its current
feature, so without the archive the history resets each time a lane starts new
work. Evidence-backed passes are counted apart from bare claims, the same line
the pipeline map draws between `done` and `passed-no-evidence`.

Beside it, GET /api/workflows/skill-usage reports which skills and plugins the
sessions actually reach for. Only PreToolUse rows are counted: every call also
emits a PostToolUse, and counting both would double every number. A plugin's
total includes calls to the MCP tools it ships, so one used purely through MCP
does not read as unused.

Still dropped from issue #6: the agent collaboration network and the subagent
effectiveness scorecards.

docs/LANES.md

@@ -464,6 +464,24 @@ The lane is resolved from the working directory, so no id is needed (pass one to
 
 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.
 
+### Aggregate pass rates across lanes
+
+`GET /api/lanes/pipeline-stats` answers the other question about node states —
+not "where is this lane now" but "how often does this stage actually pass". It
+counts every stage record of every lane **and** every archived feature, grouped
+by pipeline template:
+
+- `entered` — records that resolve onto the node (aliases included).
+- `failed` — `result: "fail"`; `passed` is the rest, so `passed + failed === entered`.
+- `withEvidence` — the passes that carry evidence, kept apart from `passed`
+  because a claim and a proof are not the same fact (the same line the five node
+  states draw between `done` and `passed-no-evidence`).
+
+Archived features matter here: a lane's own `stages` only holds its current
+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`).
+
 ## 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.