agent capabilities live in a swarm KV record, set from swarmctl

An agent's capabilities move from the hive's meta repo
(`meta/capabilities.json`, injected as `HIVE_CAPABILITIES`) into the
`capabilities` field of its key in a new `agent-permissions` KV bucket,
which swarm-controller alone writes.

- swarm-queue-client: `agent_permissions` (bucket, key, `AgentPermissions`,
  direct-get read, the import subject and its wire types).
- swarm-controller: creates the bucket at start; `GET|PUT|DELETE
  /api/agents/{name}/permissions` (deny_unknown_fields and unknown
  capability ⇒ 422, duplicate ⇒ 400, agent must be declared by a hive);
  answers each hive's one-shot import, writing a key only where there is
  none and only for agents that hive's wanted state declares.
- swarmctl: `agent permissions get|set|clear`.
- swarm-nats-auth: a hive reads every key of the bucket and sends its
  import on its own subject; the controller subscribes to the imports and
  may answer them (`responses`).
- hive-c0re: reads each of its agents' keys every 30s into
  /var/lib/hyperhive/swarm-agent-permissions.json and restarts an agent,
  gracefully, when its capabilities change. Unset is the compiled-in
  default (ruth: manage_root_agent; everyone else: none). A failed read
  keeps the stored value. On first boot it seeds that file from
  meta/capabilities.json, sends the grants to the controller, and deletes
  the file once the controller answers.

Deleted: the capabilities.json reader/writer, `HIVE_CAPABILITIES` in the
rendered meta flake, ruth's capability seed, the capabilities half of the
permissions rebuild job (`PermPayload::Capabilities`/`Combined`), the
dashboard's capabilities table and `capabilities_changed` event, and the
now-unused `Capability::description`.

Part of #5170.

docs/agent-lifecycle/config-changes.md

@@ -253,8 +253,9 @@ the operator review and merge it. By design, no second, mount-shaped
 path reaches the same file without the review.
 
 Agents holding the `manage_root_agent` capability (granted per agent in
-`capabilities.json`; see `hive-sh4re/src/permissions.rs`) get additional
-host-side bind mounts via `set_nspawn_flags`:
+the swarm's `agent-permissions` record; see
+`docs/process/conventions.md#capabilities`) get additional host-side bind
+mounts via `set_nspawn_flags`:
 
 - `/var/lib/hyperhive/agents/` → `/agents/` (RW) — **every** agent's
   proposed repo, not just direct children. The capability means "may
@@ -267,16 +268,13 @@ host-side bind mounts via `set_nspawn_flags`:
 An agent without the capability only has its direct children's config
 dirs.
 
-⚠️ nspawn bakes bind flags at container start, so granting or
-revoking this capability doesn't change any mount until that agent's
-container is rebuilt/restarted.
+⚠️ nspawn bakes bind flags at container start, so hive-c0re restarts
+an agent, after its current turn, when its capabilities change.
 
-The root agent gets the capability by default, seeded on its autodeploy
-path (`workers::auto_update::ensure_root_agent`) so the recovery mounts
-are there from its first container. That seed only fires while
-`capabilities.json` doesn't exist yet: any grant or revoke through
-the dashboard creates the file, so a revoked root-agent grant stays
-revoked and isn't re-applied on the next hive-c0re restart.
+The root agent holds the capability by default: an agent whose record
+leaves `capabilities` unset gets the hive's default, which is
+`manage_root_agent` for `ruth` and nothing for every other agent.
+Setting `"capabilities": []` for her revokes it.
 
 Each proposed repo (`/agents/<n>/config/`) is pre-configured
 with `applied` as a git remote pointing at