refactor!: rebrand CCAM to AgentHub

Clean break, no compatibility alias. Renames the product name, the CLI
binary (`ccam` -> `agenthub`), the env var prefix (`CCAM_` ->
`AGENTHUB_`), the Prometheus metric namespace (`ccam_*` ->
`agenthub_*`), the tmux session prefix (`ccam-lane-<id>` ->
`agenthub-lane-<id>`), the per-repo runtime profile directory
(`.ccam/profile` -> `.agenthub/profile`), the lanes state root
(`~/.claude/ccam-lanes` -> `~/.claude/agenthub-lanes`), the bundled
plugins (`plugins/ccam*` -> `plugins/agenthub*`) and their slash
commands (`/ccam-doctor` -> `/agenthub-doctor`, `/ccam:*` ->
`/agenthub:*`).

Because there is no alias, an existing install has to be updated by
hand: rename its `.ccam/profile` directory and any `CCAM_*` variables,
and reinstall the plugin under its new name.

Two other name families are deliberately left alone here, since they are
not just strings: the `Claude-Code-Monitor` repository/marketplace name,
and the `agent-dashboard` npm package plus its `~/.claude/agent-dashboard`
runtime directory, which holds the live database and needs a migration
rather than a rename.

Verified: server 1406/1406, client 459/459, `grep -i ccam` clean across
tracked files, `openapi.yaml` regenerated (95 paths, unchanged count).

plugins/agenthub-workflows/commands/dag.md

@@ -0,0 +1,25 @@
+---
+description: Print the orchestration DAG edges (parent→child subagents) for a session.
+argument-hint: "[session-id]"
+---
+
+Print the multi-agent orchestration DAG for a session from `http://localhost:4820`.
+
+The session id is **$ARGUMENTS**. If empty, fetch `curl -s 'http://localhost:4820/api/sessions?limit=1'` and use the most recent session, stating which id you picked. If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
+
+Fetch the workflow intelligence and read its `orchestration` dataset:
+
+```
+curl -s http://localhost:4820/api/workflows/$ARGUMENTS
+```
+
+`orchestration` contains the DAG nodes (agent id, type, model, status, depth) and parent→child edges.
+
+Print, concisely:
+
+1. **One-line topology** — `root → depth <N>, fan-out <max>, <agent count> agents`.
+2. **Edge list** — one line per edge, grouped/ordered by depth:
+   `depth d: parent[model] → child[type, status]`
+3. **Leaves** — list the leaf agents (no children) on one line.
+
+No tables, no preamble — just the topology line and the edges. Cite only nodes and edges returned by the API; never invent agents. If the session has no subagents, say so (single-agent session, depth 0). For a rendered tree and depth/fan-out breakdown, point the user at the `dag-map` skill.

plugins/agenthub-workflows/commands/runs.md

@@ -0,0 +1,25 @@
+---
+description: List recent Workflow-tool fleet runs with status and agent counts.
+---
+
+List recent Workflow-tool (Workflow()) fleet runs from the Agent Monitor at `http://localhost:4820`.
+
+These fleets emit **no hooks** — the dashboard ingests them from on-disk run journals, so this is independent of the hook event stream. If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
+
+Fetch the run journals:
+
+```
+curl -s http://localhost:4820/api/workflows/runs
+```
+
+Each run has a run id, status, agent count, and timing.
+
+Print, concisely:
+
+1. **Status mix** — one summary line, e.g. `8 runs: 5 completed, 2 running, 1 error`.
+2. **Recent runs** — a compact table, most recent first:
+
+   | Run ID | Status | Agents | Started | Duration |
+   |--------|--------|--------|---------|----------|
+
+Keep it terse. Cite only runs returned by the API; never invent runs. If there are no fleet runs, say so. To drill into one run's per-agent detail, point the user at the `fleet-runs` skill.

plugins/agenthub-workflows/commands/workflow.md

@@ -0,0 +1,25 @@
+---
+description: Summarize the workflow intelligence for a session — stats, complexity, and top patterns.
+argument-hint: "[session-id]"
+---
+
+Summarize the Agent Monitor workflow intelligence for a session from `http://localhost:4820`.
+
+The session id is **$ARGUMENTS**. If empty, fetch `curl -s 'http://localhost:4820/api/sessions?limit=1'` and use the most recent session, stating which id you picked. If the dashboard is unreachable, tell the user to start it with `npm start` from the repo root.
+
+Fetch the workflow intelligence:
+
+```
+curl -s http://localhost:4820/api/workflows/$ARGUMENTS
+```
+
+This returns 11 datasets: `stats`, `orchestration`, `toolFlow`, `effectiveness`, `patterns`, `modelDelegation`, `errorPropagation`, `concurrency`, `complexity`, `compaction`, `cooccurrence`.
+
+Print, concisely:
+
+1. **Header** — session id, total agents, max depth, and total tool calls (from `stats` / `orchestration`).
+2. **Complexity** — the numeric `complexity` score and what drives it (depth, breadth, tool diversity).
+3. **Top patterns** — up to 5 recurring sequences from `patterns`, each as `sequence ×frequency`, sorted by frequency descending.
+4. **Quick signals** — one line each: concurrency lane count (`concurrency`), subagent success rate (`effectiveness`), and total errors with origin depth (`errorPropagation`).
+
+Keep it terse — this is a one-shot. Cite only numbers returned by the API; for deeper analysis point the user at the `dag-map`, `delegation-audit`, `concurrency-report`, or `error-propagation` skills.