feat(agents): wire domain reviewers into ship-feature(-lane) review stage

Route Stage 4 / review-phase reviews to ccam:backend-reviewer,
ccam:frontend-reviewer, ccam:mcp-reviewer (parallel to the generic Code
Reviewer) by which of server/, client/, mcp/ the diff touches. Give each
reviewer a parseable verdict line and project memory to match qc-local's
rigor, and update docs/LANES.md's per-stage agent description accordingly.

skills/ship-feature-lane/SKILL.md

@@ -119,9 +119,16 @@ The e2e hook doesn't run migrations itself — it tests the already-running stac
 - `ccam stage review --status running`, then launch a fresh-context reviewer agent (Agent tool, `subagent_type: Code Reviewer` — FOREGROUND, **never `fork`**; a reviewer who already watched you write the code is not a reviewer). Hand it ONLY: the lane's working directory, the lane spec path (requirement + acceptance criteria), the diff commands, and the brief below. Do NOT summarize your own implementation for it, and do NOT pre-empt findings — let it read the diff cold.
   - Run the **`code-review` skill at effort `high`** on the feature diff vs `origin/development` — the deterministic gate, not an ad-hoc read. No PR is open yet, so point it at the local diff: `git diff origin/development...feat/<slug>` (and `git log origin/development..feat/<slug>` for commits). ONLY if the `code-review` skill is unavailable in its session, fall back to a manual review of that diff (correctness, security, tests, migration/contract safety, this repo's `CLAUDE.md` + `.claude/rules/` boundaries).
   - Final line: `REVIEW: CLEAN` or `REVIEW: FINDINGS — <n>`, with the findings listed above it as `path:line — severity — problem — suggested fix`.
-- Triage its findings with **receiving-code-review** judgment (verify each, neither blind agreement nor blind rejection) and apply what's worth applying on the feature branch. Changed source → re-run **from Stage 1b**; changed only tests → **from Stage 2**. Keep the findings + your resolutions — the senior gate reads them.
+- **Domain reviewers, in parallel with the above (same message, separate Agent calls).** Check `git diff --name-only origin/development...feat/<slug>` for touched layers and launch every matching one — FOREGROUND, fresh context, **never `fork`**, addressed as `ccam:backend-reviewer` / `ccam:frontend-reviewer` / `ccam:mcp-reviewer` (plugin-qualified — no lane install needed, unlike `qc-local`/`senior-gate-reviewer`):
+  - Any path under `server/` → `ccam:backend-reviewer`.
+  - Any path under `client/` → `ccam:frontend-reviewer`.
+  - Any path under `mcp/` → `ccam:mcp-reviewer`.
+  - None of those three touched (root/`skills/`/`agents/`/`scripts/`/docs-only change) → skip all three; the generic Code Reviewer above is the only gate.
+  - Hand each ONLY the lane's working directory and the diff range `git diff origin/development...feat/<slug>` — each scopes itself to its own domain's files even though the diff range is the same for all.
+  - Each ends with its own parseable line: `BACKEND-REVIEW:` / `FRONTEND-REVIEW:` / `MCP-REVIEW:` — `CLEAN` or `FINDINGS — <n>`.
+- Triage ALL findings — the generic review plus every domain reviewer that ran — together with **receiving-code-review** judgment (verify each, neither blind agreement nor blind rejection) and apply what's worth applying on the feature branch. Changed source → re-run **from Stage 1b**; changed only tests → **from Stage 2**. Keep the findings + your resolutions — the senior gate reads them.
 - The Stage-6 `qc-local` report covers the user-flow review for the senior gate.
-- `ccam stage review --evidence "<findings count> findings, resolved"`
+- `ccam stage review --evidence "<total findings count across all reviewers that ran> findings, resolved"`
 
 ### 5 — QC plan  *(bound the test scope before any browser QC)*
 - Author a **QC Plan** the browser-QC agents (Stage 6 now, and a future Stage 13 once dev-QC exists) will execute against — so QC covers everything that matters and nothing that doesn't (no missed scenarios, no wandering into unrelated areas). Derive it from the acceptance points (lane spec) + the real change surface (`git diff origin/development...feat/<slug>` and `--stat`). Three parts:

skills/ship-feature/SKILL.md

@@ -97,8 +97,23 @@ you dropped back to.
   a reviewer. It runs the **code-review** skill on the working diff
   (see also **superpowers:requesting-code-review** for what to hand over).
   Final line: `REVIEW: CLEAN` or `REVIEW: FINDINGS — <n>`.
-- Apply what is worth applying with **superpowers:receiving-code-review**
-  judgment: verify each point, neither blind agreement nor blind rejection.
+- **Domain reviewers, in parallel with the above (same message, separate
+  Agent calls).** Check `git diff --name-only` (against the base this task
+  started from) for touched layers and launch every matching one —
+  FOREGROUND, fresh context, never `fork`, addressed as `ccam:backend-reviewer`
+  / `ccam:frontend-reviewer` / `ccam:mcp-reviewer`:
+  - Any path under `server/` → `ccam:backend-reviewer`.
+  - Any path under `client/` → `ccam:frontend-reviewer`.
+  - Any path under `mcp/` → `ccam:mcp-reviewer`.
+  - None of those three touched → skip all three; the generic Code Reviewer
+    above is the only gate.
+  - Hand each ONLY the repo path and the working diff — each scopes itself to
+    its own domain's files. Each ends with its own parseable line:
+    `BACKEND-REVIEW:` / `FRONTEND-REVIEW:` / `MCP-REVIEW:` — `CLEAN` or
+    `FINDINGS — <n>`.
+- Apply what is worth applying — the generic review plus every domain
+  reviewer that ran — with **superpowers:receiving-code-review** judgment:
+  verify each point, neither blind agreement nor blind rejection.
 - Changed code in response? Re-run the `tests` phase.
 
 ### gate — evidence before the completion claim