docs: the hive has no approval queue

config-changes.md (was approvals.md) describes config PRs, the meta flake
and helper events; the approval queue, its kinds, the withdraw path, the
job-queue dispatch and ApprovalResolved go. Every other page drops the
approvals table, endpoints, event, tool group, hivectl verbs, dashboard
section and the loose-end/cancel kind, and links to the renamed page.

docs/agent-lifecycle/persistence.md

@@ -20,8 +20,6 @@ keeps its state, purging it doesn't.**
 
 Beyond that:
 
-- **hive-c0re keeps approvals forever** — they're an audit trail, not a
-  cache. Nothing about them ever ages out.
 - **Broker messages**: acked ones vacuum after 30 days; anything
   undelivered or delivered-but-not-yet-acked is always kept, however
   old.
@@ -40,8 +38,8 @@ schemas, file layouts, and internal migration mechanics.
 
 ### `/var/lib/hyperhive/db/broker.sqlite` (host)
 
-Six tables, all in one file — two queues, a small key/value table,
-the read-only schedule header/targets split, and the per-agent
+Five tables, all in one file — the message queue, a small key/value
+table, the read-only schedule header/targets split, and the per-agent
 power-intent registry:
 
 - `messages` — every inter-agent / operator-bound message.
@@ -56,8 +54,6 @@ power-intent registry:
   per-agent store — see [`/harness/` contents
   below](#state-dirs-per-agent) for where reminders (and todos)
   live.
-- `approvals` — the queue. `agent / kind (update_meta_inputs) /
-  commit_ref / requested_at / status / resolved_at / note`.
 - `scheduled_prompts` — the scheduled prompts left from before they
   moved to swarm level ([`swarm/schedules.md`](../swarm/schedules.md)).
   `owner / body / interval_seconds (NULL = one-shot) /
@@ -86,8 +82,6 @@ Retention:
   rows are always kept — the harness `ack_turn`s only after a
   successful turn, so `requeue_inflight` can still requeue
   an unacked row on a crash.
-- hive-c0re keeps approvals indefinitely — an audit trail. `actions::destroy`
-  rows stay visible to anything that queries by id.
 - Scheduled prompts: nothing deletes them; the rows stay as they are.
 - `agent_power` rows live until the operator destroys the agent (one row per
   agent — nothing to vacuum).
@@ -362,10 +356,10 @@ unless it holds the capability, nothing else.
 
 Under `/var/lib/hyperhive/applied/<name>/` — the hive-c0re-only
 applied repo. Tracks `flake.nix` (module-only boilerplate; never
-edited after first spawn) + `agent.nix` (the actual config; the
-root agent's edits land here via the approval flow) + any other
-files committed via the approval flow. `.git/` carries the proposal /
-approved / building / deployed / failed / denied tag history.
+edited after first spawn) + `agent.nix` (the actual config; edits land
+here from merged config PRs) + any other files those PRs commit.
+`.git/` carries the proposal / approved / building / deployed / failed /
+denied tag history.
 
 Under `/var/lib/hyperhive/meta/` — the swarm-wide deploy flake plus
 system-level config files. Single git repo for the whole host; hive-c0re
@@ -411,18 +405,17 @@ hive-c0re renders containers onto `meta#<n>` at creation.
 See [For operators](#for-operators) above for what each action does to
 an agent's state. The mechanics, for completeness:
 
-- `DESTR0Y` also drops the systemd drop-in and fails any pending
-  approvals; reviving the agent is `swarmctl agent create` with the same
-  name and hive, which reuses the kept state.
+- `DESTR0Y` also drops the systemd drop-in; reviving the agent is
+  `swarmctl agent create` with the same name and hive, which reuses the
+  kept state.
 - `PURG3` wipes `/var/lib/hyperhive/{agents,applied}/<name>/` — the
   union of everything `DESTR0Y` left behind.
 
 `actions::destroy` implements the root/bootstrap agent's specialness as a soft policy
 guard that refuses to destroy it, backstopped by
 `auto_update::ensure_root_agent`, which recreates it on the next
-hive-c0re startup if it's ever absent (bypassing the approval queue,
-as required infrastructure) — so even without the guard, destroying it
-would only be transient.
+hive-c0re startup if it's ever absent — so even without the guard,
+destroying it would only be transient.
 
 ### btrfs subvolumes for `/var/lib/hyperhive/agents/<name>`