docs: a config change is a PR from a clone, not an edit in place

Seven places described an authoring flow that does not exist: the
manager editing and committing a child's config in the bind-mounted
config dir. mara, on the snapshot issue: "the pr workflow is the main
one, anything else is legacy … the config dir in agent container is
read only copy to see own config … changes need to go through local
clone and via forge".

Two of the seven are the request_init_config MCP tool description and
its args struct, which are rendered into the system prompt of every
agent holding the approvals tool group. A wrong tool description is not
a stale comment; it is an instruction the whole hive reads as fact,
which is why the claim kept being repeated back.

The init tool creates the repo and seeds it. Nothing else. Tailoring
the seeded template is not a separate mechanism - it is the ordinary
config-change flow, a PR reviewed like any other.

Prose only; the code already implements the PR flow (an approval's
commit_ref is a PR number). Where a doc justified the parent's
read-write mount on the child's config dir with the authoring model,
the justification is removed rather than replaced: that mount is a
defect tracked on its own issue, and it should not read as intentional
while it waits.

docs/agent-hierarchy.md

@@ -143,7 +143,9 @@ can't:
 The manager container's nspawn bind set:
 
 - `HOST_AGENTS_ROOT (/var/lib/hyperhive/agents) → /agents` RW — so the
-  manager can edit any agent's proposed config repo
+  manager can manage any agent's state dir. Config is **not** authored
+  here: a config change is a PR from a clone, and `<agent>/config/` is
+  a copy for reading (its write access is a defect tracked separately)
 - `HOST_APPLIED_ROOT (/var/lib/hyperhive/applied) → /applied` RO — so
   the manager can diff against what's deployed
 - `HOST_META_ROOT (/var/lib/hyperhive/meta) → /meta` RO — so the