feat(lanes): surface child worktrees on a lane card + detect Superpowers skills

Adopting the main repo as its own lane now gets stage detection
(cwd matches, same as any other lane), and its card lists every
managed-worktree lane provisioned from it with a jump-to link.
Also add the two missing Skill-tool detect rules (implement, ship)
so detection covers all four Superpowers workflow phases, not just
plan/review.

docs/LANES.md

@@ -32,6 +32,8 @@ ccam lanes add --repo /path/to/repo --title "My Feature" --base main --slug my-f
 
 `--title`, `--base`, and `--slug` are optional. The CLI waits for background provisioning to finish and reports either the ready lane or its failure notes.
 
+Adopting your main repo (`ccam lanes add --cwd $(pwd)`) is also how you get stage detection working for sessions that work directly in it rather than in a worktree — see "Superpowers skill invocations" below. Once adopted, that lane's own card lists every managed-worktree lane whose `source_repo` matches its `cwd`, each a clickable link to jump to that lane.
+
 Adding a lane through the dashboard's "+ Add lane" flow also auto-runs, best-effort, in parallel: `ccam lanes profile init` (only if a Node.js project is detected — most repos won't be, and that's a normal outcome, not a failure), `ccam lanes agents install`, and `ccam lanes mcp sync`. None of the three blocks the lane from being created or from each other — a lane whose repo has no MCP servers configured, for instance, still gets created and is still usable, just without a synced `.mcp.json`. The modal shows a ✓/✗ summary of the three results and stays open until dismissed (Cancel/X) — it does not auto-close. Run any of the three manually later (from the lane's own card, or the CLI) if the automatic attempt didn't apply.
 
 ## Destructive lane actions
@@ -672,6 +674,23 @@ to the flattened input. Either way the result is capped at 120 characters
 lane's tooltip sometimes shows a file path or a skill name rather than a shell
 command: it's whichever of the fields above the matching rule's `tool` carried.
 
+### Superpowers skill invocations
+
+The built-in `default` pipeline's `plan`, `implement`, `review`, and `ship`
+nodes each carry a `{"tool": "Skill", "match": "..."}` rule matching the
+Superpowers workflow skill names (`brainstorming`/`writing-plans`,
+`executing-plans`/`subagent-driven-development`, `code-review`/
+`requesting-code-review`, `finishing-a-development-branch`). Invoking one of
+these skills is a much stronger signal than a matched Bash command, but it is
+still detection, not declaration — it renders dashed amber and never `done`,
+same as every other detected stage.
+
+Detection only ever attributes to a lane whose `cwd` matches the hook's
+session `cwd` (see "Which lane a signal is credited to" above). A session
+working directly in a source repo that was never itself adopted as a lane —
+run `ccam lanes add --cwd $(pwd)` from that repo to fix that — gets no
+detection at all, because no lane owns that `cwd`.
+
 ### Detection expires
 
 Forward-only would otherwise park a lane at the highest stage it ever touched: