fix(3044): a parent's mount of a child's config is read-only

The parent's copy is for reading a child's config; a change to it is a PR
on the child's repo, made from a clone and merged after review. A
writable mount is a second path to the same file that skips that review,
which makes the boundary a convention rather than a permission.

Confirmed with ruth before flipping: it clones from the forge and opens a
PR, including for a brand-new child's first config.

The prose was the larger half. docs/approvals.md did not merely describe
the old mount, it *instructed* agents to use it ("can therefore edit,
commit, and submit changes for any of its direct children directly inside
its container"), and the doc comment in host_config.rs asserted a
dependency that never existed: the InitConfig seed runs as hive-c0re
against the host path, and read_only on a bind constrains writers inside
the container only. That comment is what produced issue #3206, now closed
as invalid.

docs/persistence.md

@@ -314,12 +314,12 @@ Under `/var/lib/hyperhive/agents/<name>/`:
 
 ### Parent access to child state
 
-A parent agent gets each direct child's `state` and `config` dirs
-bind-mounted **read-write** (`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 (e.g. seeding notes, clearing a stuck
-sentinel) as well as reading it.
+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 (e.g. seeding
+notes, clearing a stuck sentinel) as well as reading it.
 
 **`harness` is not mounted at all.** It holds the child's own runtime
 material — `bash-tasks/`, the turn-stats and event sqlite dbs — and
@@ -329,11 +329,18 @@ never an argument so much as the side-effect of one loop treating all
 three dirs alike. hive-c0re reads a child's harness dir **directly on the
 host** when it wants those stats, which needs no mount into the parent.
 
-`config` is still RW, and **nothing justifies that**: a config change is
-a PR on the child's config repo, made from a clone, so the bind-mounted
-`config` dir is a read-only *copy* for reading a child's config — not a
-tree anyone edits in place. Narrowing it is tracked separately, and
-depends on relocating where `InitConfig` seeds.
+**`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
+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
+boundary a convention rather than a permission.
+
+⚠️ Not to be confused with the seeding done when an `InitConfig`
+approval resolves: that writes the child'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, and
+reading them as the same thing is what kept this mount writable.
 
 Per-child isolation still holds: a container only ever has its *own*
 dirs plus its direct children's bind-mounted, never a sibling's.