fix(lanes,reload): count a pipeline run by declarations, and stop the two reload commands merging

Closes #26, #25.

`runs` is the denominator every pass rate on the Workflows page is read
against, and any backwards move opened a new one. Stage detection bounces by
design — one feature reads `implement → tests → implement` as the session
edits, runs the suite and edits again — so a single feature was recorded as
five or six runs, and a lane in constant use reported a handful of passes
spread across dozens of phantom runs. A backwards move now opens a run only
when it is DECLARED; a backwards detection continues the run in flight.
Reaching the final node still closes the run for either, since work after
`done` is new work however it was observed. Replayed over this repo's own lane
the rule takes 26 recorded runs down to the 5 features that actually shipped
through it. The panel itself is unchanged: passes are still declarations only.

`/reload-plugins` and `/reload-skills` were typed back to back. Claude Code
opens its slash-command menu the moment `/` is typed and the Enter that follows
lands on that menu, so the second command was appended to the line still in the
composer and the pane submitted `/reload-plugins/reload-skills` — which Claude
Code runs as `/reload-plugins` with an argument, never reloading skills, and
leaving a stray prompt turn in the scrollback. Reproduced and fixed against a
live pane: SETTLE_MS (1s) between the two sends, which makes
`reloadOpenSessions` async rather than block the event loop, and the same pause
in the detached update-all worker.

docs/LANES.md

@@ -599,6 +599,19 @@ contributes at most one record per node, however many times it ran — so this
 narrows the history, it does not skew a rate. The Workflows page renders this as one bar per node (see
 `client/src/components/workflows/LanePipelinePanel.tsx`).
 
+**A new run is opened by a DECLARATION, never by a detection alone.** `runs` is
+the denominator every rate on that page is read against, so what counts as a run
+decides whether the page is worth reading. Stage detection bounces by design —
+one feature's work reads `implement → tests → implement → tests` as the session
+edits, runs the suite, and edits again — and when any backwards move opened a
+run, a single feature was recorded as five or six of them. A real pass ends
+where the session says it ends: a backwards move only starts a new run when it
+is declared (`agenthub stage`, or a codex lane's ingest-driven declaration). A
+detection that moves backwards continues the run in flight. Reaching the last
+node still closes the run for both — work after `done` is new work by anyone's
+reading. On this repo's own lane the rule took a 26-run history down to 5, which
+is the number of features that were actually shipped through it.
+
 `?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