docs: persistence and config changes become one operator page

The operator parts of the persistence and config-changes pages merge into
agents/persistence.md. The sqlite tables, state dirs, mounts and migrations move
to 4-implementation/agent-state/persistence.md, and the deploy path, meta flake,
deploy markers, startup migrations, root container, system messages and
autoupdate move to 4-implementation/agent-state/config-changes.md. Links, code
comments and nix comments that named the old sections point at the new pages.

docs/4-implementation/swarm/builder.md

@@ -179,7 +179,7 @@ the deploy node, and the graph shows the update as failed and the deploy as
 skipped. Each ten-minute retry of a failed update declares a fresh build and
 deploy behind it for every agent whose latest deploy the failed update skipped,
 so the run that succeeds sends them (see
-[Config changes](../../2-handbook/agents/config-changes.md#the-swarms-meta-flake)). A render
+[Config changes](../../4-implementation/agent-state/config-changes.md#the-swarms-meta-flake)). A render
 equal to the committed `flake.nix` sends no lock.
 
 The controller sends a deploy to every agent a hive places whenever the pin in

docs/4-implementation/swarm/controller.md

@@ -395,7 +395,7 @@ them, and the notification router, not the controller, decides what they mean.
 A `config-pr` delivery reporting a PR merged into `main` queues a deploy
 of its `merge_commit_sha` on the one hive whose wanted state places the
 agent; with no such hive, or more than one, the controller deploys nothing. See
-[config-changes.md § Config changes](../../2-handbook/agents/config-changes.md#config-changes).
+[config-changes.md § Config changes](../../4-implementation/agent-state/config-changes.md#config-changes).
 A merge whose `closed` delivery never arrives deploys nothing either; the
 operator recovers by redelivering that delivery from the forge hook page,
 which re-enters the same handler and re-queues the deploy.
@@ -422,7 +422,7 @@ host also serves the swarm UI vhost — that's what publishes the
 endpoint, and a hook the forge can't reach would collect failed
 deliveries while looking healthy. The controller generates the HMAC
 secret on first start and keeps it
-(see [`docs/2-handbook/agents/persistence.md`](../../2-handbook/agents/persistence.md)).
+(see [`docs/4-implementation/agent-state/persistence.md`](../../4-implementation/agent-state/persistence.md)).
 
 To check it's working, push to `internal/knowledge` and look for
 `webhook: verified delivery` in `journalctl -u swarm-controller`. A

docs/4-implementation/swarm/forge-accounts.md

@@ -69,13 +69,13 @@ Two things live in the `agent-configs` Forgejo organization:
   allowlists are the `operators` team, and the agent can neither push
   `main` directly nor self-merge. An operator's merge in the Forgejo UI
   deploys the merged commit (see
-  [config-changes.md § Config changes](../../2-handbook/agents/config-changes.md#config-changes)).
+  [config-changes.md § Config changes](../../4-implementation/agent-state/config-changes.md#config-changes)).
   hive-c0re pushes nothing to this org and reads nothing from it.
   Repos stay private, so an agent can't read another
   agent's config. The agent's **persistent meta flake input** is this repo's `main` head,
   pinned by sha in `internal/meta` (`agent-<n>.url =
 git+<forge>/agent-configs/<n>.git?rev=<sha>`; see
-  [config-changes.md § Meta flake](../../2-handbook/agents/config-changes.md#meta-flake)).
+  [config-changes.md § Meta flake](../../4-implementation/agent-state/config-changes.md#meta-flake)).
 
 The `hive-forge` CLI (separate workspace crate, see
 [`README.md`](../../README.md) file map) wraps the Forgejo REST API