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/tools/README.md

@@ -40,8 +40,6 @@ debug agent behavior.
 - **[forge-cli](forge-cli.md)** — the exhaustive, autogenerated
   flag-by-flag reference for `hive-forge`, kept in lockstep with the
   binary by CI the same way `hivectl-cli.md` is.
-- **[lifecycle](lifecycle.md)** — listing the agents in a caller's own
-  subtree, plus the approval-gated config-change tools.
 - **[matrix](matrix.md)** — the matrix MCP tool surface
   (`mcp__matrix__*`) for agents with a matrix account, multiple
   accounts per agent, and declaring extra MCP servers generally.

docs/tools/lifecycle.md

@@ -1,58 +0,0 @@
-# Lifecycle and approvals tools
-
-Two tool groups govern agent lifecycle management and config changes.
-The server scopes both to the caller's **own subtree** (topology-enforced
-per `topology.json`: a child, a child's child, every agent below them —
-plus the caller itself). No privileged class exists to belong to; the
-root agent reaches every agent purely because the check is transitive and
-everything sits under it.
-
-## `lifecycle` tool group
-
-No operator approval required. The caller's own subtree.
-
-### `list_containers()`
-
-List the caller's whole **subtree** with running status — children,
-their children, every agent below them. The calling agent is part of its
-own subtree, so it appears in its own listing; a leaf agent gets a
-one-row answer naming itself.
-
-## `approvals` tool group
-
-Meta-flake input bumps route through the operator approval queue.
-
-Creating a new agent is **not** in this group — agents have no tool for
-it. The swarm controller's `InitAgentConfigRepo` job scaffolds a new
-agent's config repo (`POST /api/agents`, see
-`swarm-controller/`), and the operator spawns the container from the
-dashboard (`◆ R3QU3ST SP4WN` / `Spawn` approval, routed via
-`HostRequest::RequestSpawn`).
-
-Config changes on an existing agent go through a **forge PR** on the
-agent's `agent-configs/<name>` repo (queues a `MergeConfigPr` approval
-on open/update — no MCP tool involved), not a tool call. See
-`docs/agent-lifecycle/approvals.md`.
-
-### `request_update_meta_inputs(inputs?, description?)`
-
-Queue an approval to run `nix flake update [inputs...]` on the meta
-flake. Pass specific input names (for example `["bitburner-agent"]`) or omit
-/ pass `[]` for all inputs. Returns immediately; the lock update runs
-on operator approval.
-
-**Doesn't** trigger container rebuilds — the operator rebuilds affected
-agents after the approval resolves.
-
-## Boundary summary
-
-| Operation                    | Requires approval? | Scope                        |
-| ---------------------------- | ------------------ | ---------------------------- |
-| `list_containers`            | No                 | Own subtree, caller included |
-| `request_update_meta_inputs` | Yes (MetaUpdate)   | Meta flake (global)          |
-
-## See also
-
-- [`docs/agent-lifecycle/approvals.md`](../agent-lifecycle/approvals.md) — full approval flow, kinds,
-  helper events (`approval_resolved`), flake.lock
-  validation.