hive-c0re: remove the approvals subsystem

Nothing submits an approval since scheduled prompts left hive-c0re, so the
queue only acted on rows written before that.

- hive-c0re: the approvals store and its migrations, approve/deny/
  resolve actions, the ResolveApproval tail node (and meta_update's
  approval_id), POST /api/approve and /api/deny, the approval views on
  /api/state, the approval_resolved dashboard event, the orphan GC,
  destroy/purge failing pending rows, and the approval rows in
  get_loose_ends. DestroyBookkeeping loses the purge flag, which only
  worded the approval-failure note.
- The CancelLooseEnd request goes: its only hive-c0re arm was the
  approval one. cancel_loose_end handles reminder and todo in the harness.
- Wire types: hive_sh4re::approvals (ReminderStats moves to inbox),
  LooseEnd::Approval, CancelLooseEndKind, HelperEvent::ApprovalResolved,
  ToolGroup::Approvals, HostRequest::{Pending,Approve,Deny} and
  HostResponse.approvals. HOST_SOCK_VERSION goes to 2 for the removed
  field.
- hivectl loses the approvals verbs; docs/tools/hivectl-cli.md is
  regenerated.
- The system prompt drops approval_resolved.
- The approvals table stays in broker.sqlite, unread, the same way the
  operator_questions table was left when its store was removed.
- An `approvals` entry still in tool-groups.json is skipped with a warning
  by ToolGroup::parse_list, like any unknown group.
- docs/agent-lifecycle/approvals.md is renamed to config-changes.md so the
  code's doc pointers resolve; its content follows in the docs commit.

hive-c0re/src/job_queue/scheduler.rs

@@ -10,10 +10,9 @@
 //! label tracks the DAG's progress (signal → swap → reconcile) instead of
 //! repeating one intent the template declared before any of it started.
 //!
-//! Per-DAG terminal work (approval resolution, `Rebuilt`) is not drained here:
-//! it runs as the DAG's focused terminal node (`ResolveApproval` /
-//! `EmitRebuilt`), dispatched through `exec::run_node` like any other node once
-//! the DAG settles.
+//! Per-DAG terminal work (`Rebuilt`) is not drained here: it runs as the DAG's
+//! focused terminal node (`EmitRebuilt`), dispatched through `exec::run_node`
+//! like any other node once the DAG settles.
 //!
 //! In-DAG growth (a `MetaLock` growing rebuild subgraphs, a `Reconcile` fanning
 //! its `Start`/`Stop`) is declared onto the builder each node is handed, and
@@ -55,7 +54,7 @@ type TransientSeen = HashMap<(String, String), bool>;
 /// `nixos-container update`, which is itself declarative). That's a property
 /// of the node set, not of the queue — it holds today but isn't enforced by
 /// the type system, so it's worth re-checking whenever a new `NodeKind` is
-/// added. The side-effect tails (`EmitRebuilt`, `ResolveApproval`) sit
+/// added. The side-effect tail (`EmitRebuilt`) sits
 /// closest to the edge: dropping or re-running one affects something outside
 /// the graph (today, a missed or duplicated notification) rather than
 /// reconverging silently.