docs: retire the agent hierarchy from every page that described it

The topology doc keeps its filename and its second half (manager
special-casing, harness unit shape) — both are cross-referenced from
other pages and neither is about the parent field. Its first half is
rewritten: what topology.json is now, and a table of what the removal
took with it, so a reader who finds `<parent>` or `set-parent` in an old
issue thread learns it went away rather than moved.

The dashboard's tree-rendering section is marked dormant rather than
deleted: the walk is still in swarm.js and retiring it is the frontend
owner's call.

docs/agent-lifecycle/persistence.md

@@ -335,24 +335,29 @@ Under `/var/lib/hyperhive/agents/<name>/`:
   - `hyperhive-turn-stats.sqlite` — per-turn timing stats.
   - `hyperhive-model` — single-line model name override file.
 
-### Parent access to child state
+### Cross-agent access to state
 
-A parent agent gets each direct child's `state` dir bind-mounted
-**read-write** and its `config` dir **read-only**
-(`bind_child_agent_dirs` in `lifecycle/host_config.rs`). The RW on
-`state` is deliberate, not an oversight: a parent manages its children,
-which includes writing into a child's state for recovery (for example seeding
-notes, clearing a stuck sentinel) as well as reading it.
+An agent holding the `ManageRootAgent` capability gets every other
+agent's `state` dir bind-mounted **read-write** and its `config` dir
+**read-only** (`bind_child_agent_dirs` in `lifecycle/host_config.rs`).
+The RW on `state` is deliberate, not an oversight: the holder recovers
+other agents, which includes writing into their state (for example
+seeding notes, clearing a stuck sentinel) as well as reading it.
 
-**`harness` isn't mounted at all.** It holds the child's own runtime
+This is the **only** cross-agent mount. #4472 removed the topology
+parent field, and with it the unconditional grant every agent used to
+get over its own direct children — an agent holding no capability now
+sees its own dirs and nothing else.
+
+**`harness` isn't mounted at all.** It holds that agent's own runtime
 material — `bash-tasks/`, the turn-stats and event sqlite dbs — and
-nothing argues for a parent reading it, let alone writing it. hive-c0re
-reads a child's harness dir **directly on the host** when it wants
-those stats, which needs no mount into the parent.
+nothing argues for anyone else reading it, let alone writing it.
+hive-c0re reads a harness dir **directly on the host** when it wants
+those stats, which needs no mount into another container.
 
 <!-- vale write-good.Passive = NO -->
-**`config` is read-only, including for the parent.** A config change is
-a PR on the child's config repo, made from a clone and merged after
+**`config` is read-only, including for the holder.** A config change is
+a PR on that agent's config repo, made from a clone and merged after
 review — so the bind-mounted `config` dir is a *copy to read*, never a
 tree anyone edits in place. Mounting it writable would leave a second
 path to the same file that skips the review entirely, which makes the
@@ -361,15 +366,15 @@ boundary a convention rather than a permission.
 
 <!-- vale write-good.Passive = NO -->
 ⚠️ Don't confuse it with the config-repo seeding hive-c0re does at
-spawn (`lifecycle::setup_proposed`): that writes the child's initial
+spawn (`lifecycle::setup_proposed`): that writes the agent's initial
 config repo as **hive-c0re, against the host path**, and `read_only` on a bind
 constrains writers *inside* a container only. The two are unrelated —
 conflating them can lead you to reason your way into thinking this
 mount should be writable when it shouldn't.
 <!-- vale write-good.Passive = YES -->
 
-Per-child isolation still holds: a container only ever has its *own*
-dirs plus its direct children's bind-mounted, never a sibling's.
+Isolation still holds by default: a container has its *own* dirs and,
+unless it holds the capability, nothing else.
 
 Under `/var/lib/hyperhive/applied/<name>/` — the hive-c0re-only
 applied repo. Tracks `flake.nix` (module-only boilerplate; never
@@ -387,13 +392,11 @@ Contents:
   `nixosConfigurations.<n>` output per agent. `flake.lock` is the
   canonical "what's deployed where." The git log is the deploy
   audit trail (one commit per successful deploy or hyperhive bump).
-- `topology.json` — parent/child agent graph
-  (`{ "alice": "root", "bob": "alice", "root": null }`).
-  Written by `topology::apply_set_parent` (the pure move-validating
-  transform) via `meta::bulk_commit_topology` (the committer — see the
-  `Reparent` node in [`docs/scheduler/coordinator.md`](../scheduler/coordinator.md)); read by
-  the dashboard, the renderer, and `<parent>` / `<children>` recipient
-  resolution.
+- `topology.json` — the agent roster (`["alice", "bob", "ruth"]`).
+  Written by `topology::reconcile` on every meta sync; read by
+  `topology::all_agents`, which is the set the `ManageRootAgent`
+  capability grants mounts over. Carried a `parent` per agent until
+  #4472; the reader still accepts that shape and keeps its keys.
 - `tool-groups.json` — per-agent MCP tool group grants
   (`{ "alice": ["messaging", "inbox", "execution"] }`). Written by
   `tool_groups::set_groups`; injected as `HIVE_TOOL_GROUPS` env