remove the list_containers and request_update_meta_inputs MCP tools

Both agent-facing tools go away end to end, with no replacement. This is
an intentional capability removal: agents can no longer enumerate their
own subtree, and can no longer queue a meta-flake input bump.

The system prompt and docs/tools/lifecycle.md land in this same commit
on purpose. A tool named in the prompt but absent from the server makes
agents confidently call something that doesn't exist, and the failure
then surfaces far from its cause.

Removed:

- MCP registrations and bodies (hive-agent-mcp), plus the now-unused
  UpdateMetaInputsArgs.
- Wire variants Request::ListDescendants,
  Request::RequestUpdateMetaInputs and Response::Containers, plus
  ContainerInfo, whose only consumer was that response.
- hive-c0re's handle_list_descendants (its whole module) and
  handle_request_update_meta_inputs, the two dispatch arms, and the
  require_group(agent, "approvals", ...) gate on the meta-inputs verb.
- The stream_enrich emoji entry and argument formatter.
- docs/tools/lifecycle.md (both tools it documented are gone), its two
  referrers, the tool-group tables and the agent-hierarchy prose.

Tool groups are kept, deliberately. ToolGroup::Lifecycle listed exactly
one tool and now lists none — it is vestigial, but the variant stays so
existing meta/capabilities.json grants still parse; retiring it is a
separate decision. ToolGroup::Approvals also listed exactly one tool,
but the group is NOT dead: check_can_cancel_approval still gates
cancel_loose_end's approval-cancel arm on it server-side.

ApprovalKind::UpdateMetaInputs stays too. Nothing in production code
produces it any more, but pre-existing approval rows may still carry it,
and the operator's own path to a meta update is unaffected — the
dashboard's POST /api/meta-update inserts the meta_update job directly,
bypassing approvals entirely.

The two format_ack tests in hive-agent-mcp that named
request_update_meta_inputs were only using it as a label string while
exercising the generic OkWarn/Ok renderer, so they are retargeted to a
surviving tool rather than deleted.

Note hive-c0re's priv_client::list_containers is a different thing (the
host-side privileged container listing behind hive-priv) and is
untouched.

Closes #4591

docs/agent-lifecycle/agent-hierarchy.md

@@ -96,7 +96,6 @@ umount-old / mount-new / restart-cascade step.
 | config change via forge PR (any descendant's config)        | any ancestor                                                                            |
 | moderate reminders (cancel any open thread of a descendant) | any ancestor                                                                            |
 | `send` / `recv` routing                                     | parent ↔ same-parent siblings ↔ self ↔ descendants; explicit allow-list for anyone else |
-| `request_update_meta_inputs` (bump meta lock)               | root agents only (today: just `manager`)                                                |
 
 "Ancestor" walks `ContainerView.parent` chains; a visited-set guards against
 cycles at dispatch time (a malformed `topology.json` can't lock
@@ -116,14 +115,11 @@ other agents don't:
   approval step — every other agent goes through a `Spawn` approval.
   Topology-wise, `ruth` is still just another root agent.
 - **Wire-protocol** — the privileged `Request` variants
-  (`Kill` / `Start` / `Restart` / `Update`;
-  `GetLogs`; `RequestUpdateMetaInputs`) — marked `*(privileged)*` in
-  `hive-core-agent-sock`'s unified `Request` enum — are reachable only
-  from the manager's socket flavour today. Planned rule for each is in the
-  table above ("any ancestor" for lifecycle/logs);
-  `RequestUpdateMetaInputs` stays
-  a root-only capability even post-milestone, not a topology rule.
-  One exception: `Wake` (inject a `from: <X>` message into the
+  (`Kill` / `Start` / `Restart` / `Update`; `GetLogs`) — marked
+  `*(privileged)*` in `hive-core-agent-sock`'s unified `Request` enum —
+  are reachable only from the manager's socket flavour today. Planned
+  rule for each is in the table above ("any ancestor" for
+  lifecycle/logs). One exception: `Wake` (inject a `from: <X>` message into the
   caller's own inbox) isn't really privileged — every per-agent daemon
   (for example `hive-forge-notify`) needs it, and sub-agents already have the
   equivalent on their own socket.
@@ -135,9 +131,10 @@ other agents don't:
   deploy log). Planned: each agent gets RW to `/agents/<descendant>/`
   for just its own subtree — the manager's full-forest RW becomes the
   "root's subtree is everything" case of that same rule. hive-c0re will
-  gate RO `/meta` access on a "meta read" capability; only
-  `request_update_meta_inputs` writes `flake.lock`, gated by its own
-  capability.
+  gate RO `/meta` access on a "meta read" capability; no agent-facing
+  path writes `flake.lock` any more — `request_update_meta_inputs` was
+  removed, leaving the operator dashboard's `POST
+/api/meta-update` as the only entry point.
 - **Prompt/tools** — the system prompt uses `<!-- role:agent -->` /
   `<!-- role:manager -->` marker blocks, and a `Flavor::{Agent,
 Manager}` switch picks the MCP tool allow-list claude sees. Both are