collapse the roles.json mount grant into the ManageRootAgent capability

The hive had two spellings of "this agent may act on agents that aren't
its children": the `ManageRootAgent` capability, which nothing checked,
and a `can_manage_top_level_agents` role in a third meta store,
`roles.json`, which owned the real grant — the bind mounts that put
another agent's state (rw) and config (ro) inside the holder's
container. The two drifted independently, and with the parent/child
hierarchy removed the role's set (`parent.is_none()`) silently became
every agent while nothing said so.

Collapse them. The mount grant now hangs off
`Capability::ManageRootAgent`, looked up through the one capability
path that already exists (`capabilities::has_cap` over
`capabilities.json`) rather than a second mechanism. `roles.json` and
everything that read, wrote or reconciled it is gone, along with its
`meta.rs` staging and commit-label wiring; nothing in the tree reads
that file any more.

The enum variant keeps its name deliberately. Renaming it would turn
every `manage_root_agent` already stored in `capabilities.json` into an
unrecognised name that `prune_unknown` drops without asking. Its
meaning, not its spelling, is what changed: "may manage any agent". The
doc comment and the description string now say that.

`top_level_agents()`/`top_level_agents_in()` are replaced by
`all_agents()`/`all_agents_in()`. Under "manage any agent" the mounted
set is every agent by definition, so the code states it instead of
deriving it from a predicate that no longer discriminates — and the
call-site comment explains that, because it otherwise reads as a
widening. The holder is no longer bound as its own virtual child: that
reproduced the own-state and own-config mounts exactly, so dropping it
loses nothing.

docs/agent-lifecycle/approvals.md

@@ -496,19 +496,24 @@ forge into its own state dir, commit on a branch, open a PR**, and let
 the operator review and approve it. By design, no second, mount-shaped
 path reaches the same file without the review.
 
-Agents holding the `can_manage_top_level_agents` topology role (see
-`hive-c0re/src/agent_config/topology.rs`) get additional host-side
-bind mounts via `set_nspawn_flags`:
+Agents holding the `manage_root_agent` capability (granted per agent in
+`capabilities.json`; see `hive-sh4re/src/permissions.rs`) get additional
+host-side bind mounts via `set_nspawn_flags`:
 
-- `/var/lib/hyperhive/agents/` → `/agents/` (RW) — all top-level
-  agents' proposed repos (not just direct children).
+- `/var/lib/hyperhive/agents/` → `/agents/` (RW) — **every** agent's
+  proposed repo, not just direct children. The capability means "may
+  manage any agent", so the mounted set is every agent.
 - `/var/lib/hyperhive/applied/` → `/applied/` (RO) — every agent's
   authoritative applied repo, including `.git`.
 - `/var/lib/hyperhive/meta/` → `/meta/` (RO) — the swarm-wide
   deploy flake.
 
-The root agent holds this role; a sub-manager that only manages a
-subtree doesn't, and only has its direct children's config dirs.
+An agent without the capability only has its direct children's config
+dirs.
+
+⚠️ nspawn bind flags are baked at container start, so granting or
+revoking this capability does not change any mount until that agent's
+container is rebuilt/restarted.
 
 Each proposed repo (`/agents/<n>/config/`) is pre-configured
 with `applied` as a git remote pointing at

docs/process/conventions.md

@@ -362,7 +362,7 @@ that allows the underlying resource access.
 
 | Capability | Effect |
 |---|---|
-| `manage_root_agent` | may lifecycle-manage the root/manager agent via `kill`/`start`/`restart` |
+| `manage_root_agent` | may manage *any* agent: bind-mounts every agent's state (rw) + config (ro) into the holder's container, plus `/applied` and `/meta` (ro). Takes effect on the holder's next container rebuild/restart |
 | `read_host_journal` | registers the `get_host_journal` MCP tool + serves `GET /journal-host` requests |
 
 **Config storage** — per-agent capabilities live in

docs/web-ui/dashboard.md

@@ -440,7 +440,7 @@ The current capabilities are:
 
 | Name | Effect |
 |------|--------|
-| `manage_root_agent` | allows the `set_status` / lifecycle tools on the root agent |
+| `manage_root_agent` | mounts every agent's state (rw) + config (ro) into this agent's container so it can manage/recover any agent |
 | `read_host_journal` | unlocks `get_host_journal` to read journald from inside a container |
 
 Each row is one agent. Columns are the capability names returned by