docs(dashboard): reframe stale 'the manager' as the root/submitting agent

Schedule columns, tool-group/capability defaults, terminal addressing
(@root), destroy/move guards, and approval-resolution notes now refer to
the root agent (or the submitting agent, for approval flows) rather than
'the manager'. Also fixed the stale 'moving the manager' move-refusal
example (the root agent is reparentable) to a cycle example.

docs/web-ui/dashboard.md

@@ -144,7 +144,7 @@ lock graph with a `visited` set — `follows` aliases and rev-less
 nodes are skipped. A `select all / select none`
 control sits above the tree. Checking inputs + submitting bumps
 the lock in `/meta/` and rebuilds the selected agents in
-sequence; each outcome reaches the manager as a `rebuilt`
+sequence; each outcome reaches the root agent as a `rebuilt`
 system event. `POST /meta-update`. While a lock-bump ripple runs,
 the panel shows a pulsing "⏳ meta-update running" banner and the
 update button is disabled (snapshot field `meta_update_running`,
@@ -305,7 +305,7 @@ The current capabilities are:
 
 | Name | Effect |
 |------|--------|
-| `manage_root_agent` | allows the `set_status` / lifecycle tools on the root manager |
+| `manage_root_agent` | allows the `set_status` / lifecycle tools on the root agent |
 | `read_host_journal` | unlocks `get_host_journal` to read journald from inside a container |
 | `query_agent_state` | allows `get_loose_ends(agent: "<name>")` calls targeting other agents |
 
@@ -319,7 +319,7 @@ agents in the assignment map have no extra capabilities.
 
 **T00L GR0UPS** — per-agent tool-group permissions. Tool groups are
 named buckets of MCP tools; each agent starts with a role default
-(agents: `messaging`, `meta`, `inbox`, `execution`; manager: all
+(sub-agents: `messaging`, `meta`, `inbox`, `execution`; root agent: all
 groups). Checking / unchecking stages which groups are active for the
 agent; the page-level **save all** button (below) commits it. Columns
 come from `GET /api/tool-groups`. A rebuild is queued so
@@ -367,7 +367,7 @@ share enough conceptual ground to live together.
 scheduled prompts. **Single-table layout**: each schedule is
 one `<tr>`; columns are
 `# | src | next | every | owner | body | …agents… | actions`.
-Agent columns are dynamic — `operator` + `manager` + every
+Agent columns are dynamic — `operator` + `root` + every
 live container + any extra name that appears as a target on
 some schedule but isn't a current container (same
 `buildTargetChips` membership rule the new/edit forms use,
@@ -583,7 +583,7 @@ stream sits a terminal-style compose box: `@name` picks the recipient
 (sticky via localStorage; auto-complete from the live container list,
 Tab/Enter to confirm; `@*` broadcasts). `POST /api/op-send` drops
 `{from:"operator", to, body}` into the broker; the resulting SSE frame
-re-renders the terminal row. Manager is addressed as `@root`.
+re-renders the terminal row. The root agent is addressed as `@root`.
 
 ## H0M3 page (`/`)
 
@@ -925,12 +925,12 @@ frosted-mauve bar slides up from the bottom of the viewport
   - `■ ST0P` — running agents only
   - `▶ ST4RT` — stopped agents only
   - `↻ R3BU1LD` — always available
-  - `DESTR0Y` / `PURG3` — sub-agents only (disabled if manager selected)
+  - `DESTR0Y` / `PURG3` — sub-agents only (disabled if the root/bootstrap container selected)
   - `⇡ M0V3 → ROOT` — promote selected agents to top-level
     (parent = null); disabled when all selected are already at root.
     Backend `topology::set_parent` refuses moves it can't satisfy
-    (e.g. moving the manager) and the refusal surfaces in the
-    failure roll-up.
+    (e.g. a move that would create a cycle) and the refusal surfaces
+    in the failure roll-up.
   - `⇢ M0V3 → [select]` — inline picker available for any
     selection size. The dropdown lists every container that isn't IN
     the selection itself nor a descendant of any selected agent
@@ -958,14 +958,14 @@ renderApprovals`) with three stacked sections:
   so a stale approval stands out; the `.stale` class flips
   precisely at the 3600s boundary rather than at the next
   `renderApprovals` call.
-- **what-changed body** — the manager's description, then
+- **what-changed body** — the submitting agent's description, then
   drill-in triggers: `↳ view diff` opens the diff in the side
   panel; `↳ commit on forge ↗` deep-links the proposal commit
   into `agent-configs/<agent>` (shown only when `forge_present`).
   Spawn approvals show a one-line "container will be created"
   note instead.
 - **decision actions** — `◆ APPR0VE` and `DENY`. Deny pops a
-  `prompt()` for an optional reason carried to the manager as
+  `prompt()` for an optional reason carried to the submitting agent as
   `HelperEvent::ApprovalResolved.note`.
 
 The diff panel has a 3-way base toggle — **vs applied** (the
@@ -1012,7 +1012,7 @@ that's a browser-level decision, not ours.
   updates derived approvals state from the event.
 - `POST /api/deny/{id}` (`note=<reason>`, optional) — deny a pending
   approval with an optional operator-supplied reason. The reason
-  travels to the manager as `HelperEvent::ApprovalResolved.note`
+  travels to the submitting agent as `HelperEvent::ApprovalResolved.note`
   and also rides on the dashboard's `ApprovalResolved` event.
   Dashboard prompts via the themed `themedPrompt()` dialog on
   click — a resizable `<textarea>` where Enter submits and
@@ -1157,7 +1157,7 @@ that's a browser-level decision, not ours.
 - `POST /api/schedules` — operator-direct schedule create:
   `{ targets, body, first_fire_at_unix, interval_seconds?, description? }`.
   Agent-initiated schedules go through the approval queue instead
-  (manager MCP `request_schedule_prompt`).
+  (via the `request_schedule_prompt` MCP tool).
 - `PATCH /api/schedules/{id}` — partial edit. JSON body
   `{ body?, description?, interval_seconds?, next_fire_at_unix?,
   targets_add?, targets_remove? }`.