agent permissions: one set, tool groups included, set at agent creation

mara on #5170: "dont split caps and perms. its all perms. / dont include
the now empty tool groups / nothing set -> default / also add perms to
agent creation screen".

- hive-sh4re: one `Permission` enum (messaging, meta, inbox, execution,
  web_tools, manage_root_agent) replaces `ToolGroup` and `Capability`;
  `lifecycle`/`forge` are gone. `Permission::default_for` is the default
  for an agent the swarm sets nothing for.
- The record is `{ "permissions": [...] }`. Missing key, unset field or
  no successful read yet = default; `[]` = none; a failed read after a
  good one keeps the last value.
- hive-agent reads its own key every 10s and builds each turn's --tools,
  --allowedTools and MCP config (rewritten before every turn) from it;
  the subagent daemon reads it on each start/continue. Agents get a
  read-only grant on their own key.
- hive-c0re restarts an agent only when its manage_root_agent changes.
  The import now merges meta/capabilities.json and meta/tool-groups.json
  into one list per agent and deletes both; the "import pending, don't
  read" decision is `ImportOutcome::read_allowed`, table-tested.
- swarm-controller: `GET /api/permissions` (names + default) and an
  optional `permissions` on `POST /api/agents`, stored before the job is
  queued. swarm-ui's create-agent form gets a permissions field.
- Deleted: HIVE_TOOL_GROUPS and its forward to the subagent daemon,
  tool_groups.rs, ruth's tool-group seed, the permissions rebuild job
  (PermPayload/WritePermFile/perm_change), the dashboard permissions tab
  and its stale-entries panel.

Part of #5170.

docs/tools/subagent.md

@@ -399,23 +399,24 @@ particular `--tools` does **not** filter `mcp__*` tools.
 
 **A subagent gets exactly the built-ins its parent agent has, plus one
 deliberate exception** — the base resolution
-(`hive_sh4re::permissions::subagent_builtin_tools_arg`, wrapping the
-harness's own `builtin_tools_for`) from the same `HIVE_TOOL_GROUPS`:
+(`hive_sh4re::permissions::subagent_builtin_tools_for`, wrapping the
+harness's own `builtin_tools_for`) over the agent's permissions, which the
+daemon reads from the swarm on each `start`/`continue`:
 `Edit`, `Glob`, `Grep`, `Read`, `Skill`, `Write`, plus `WebFetch`/
-`WebSearch` for an agent granted the `web_tools` tool group and not
-otherwise. See
+`WebSearch` for an agent granted `web_tools` and not otherwise. A running
+subagent keeps the tools it started with. See
 [the harness's own allowlist](../turn-loop/mcp.md#tool-allowlist-hive_sh4repermissionsallowed_builtin_tools)
 for what that list contains and why.
 
 The exception: **a subagent gets Claude's built-in `Bash` iff its parent
-holds the `execution` tool group** — the group that already grants the
+holds the `execution` permission** — the permission that already grants the
 parent shell execution, via the out-of-process `bash` MCP server
 (`mcp__bash__run`/`status`/`kill`). A subagent has no MCP server of its
 own by default (see [MCP servers](#mcp-servers---strict-mcp-config)
 below), so there is no `mcp__bash__*` for it to inherit that capability
 through; it gets Claude's own tool instead. The rule is the capability
 transfers, not the mechanism — the parent itself never gains built-in
-`Bash` no matter which groups it holds, only a subagent spawned by an
+`Bash` no matter which permissions it holds, only a subagent spawned by an
 `execution`-holding parent does.
 
 Inheriting rather than listing is the point: a hardcoded subagent list