docs: refresh for the dashboard rework + recent harness commits

- web-ui.md: side panel, approval card + 3-way diff base, stats
  page, forge config links, removed agent.nix viewer, per-agent
  loose-ends inline answer.
- approvals.md: forge mirror section + diff base toggle.
- turn-loop.md: recv(max), get_logs, remind, loose-ends, whoami.
- agent.md / manager.md prompts: recv(max), remind, get_logs.
- CLAUDE.md: forge.rs / stats.rs / hive-forge.nix in the file
  map, scratchpad refresh.

also: forgejo migrations.ALLOW_LOCALNETWORKS = true so an in-hive
mirror of the hyperhive repo can import from a localhost source.

docs/approvals.md

@@ -28,7 +28,10 @@ happens after a decision lands.
    force-push, or `rm -rf` the proposed repo and the queued
    approval still points at an immutable git object inside
    applied.
-4. Operator sees the diff on the dashboard, clicks ◆ APPR0VE (or
+4. Operator sees the proposal as a card on the dashboard — a
+   full multi-file diff, toggleable between three bases (vs the
+   running tree / vs the last approved proposal / vs the
+   previous queued proposal) — and clicks ◆ APPR0VE (or
    `hive-c0re approve <id>` on the CLI).
 5. hive-c0re moves the working tree to `proposal/<id>` and runs
    the build under a sequence of tags (see below). On success,
@@ -158,6 +161,30 @@ approval id to retry. Because tags are first-class git objects,
 rejected and failed trees stay browsable forever — `git log
 --tags` in the applied repo is the audit trail.
 
+### Forge mirror
+
+When the bundled `hive-forge` container is running — on by
+default, `hyperhive.forge.enable` — hive-c0re mirrors every
+agent's applied repo into a private `agent-configs` Forgejo
+org. `forge::push_config(<name>)` pushes `applied/main` plus
+every tag to `agent-configs/<name>` after each ref mutation:
+the spawn that seeds `deployed/0`, every `request_apply_commit`
+(which plants `proposal/<id>`), every approve / deny, and a
+sweep at startup. Pushes are best-effort — a missing or stopped
+forge never blocks a deploy.
+
+The org is private and agents are not members, so only the
+`core` user (a Forgejo site admin) can read it: an agent can't
+reach another agent's config — or even its own — through the
+forge. The tokenised push URL is passed inline to `git push`,
+never written into `applied/<n>/.git/config`; that repo is
+RO-bind-mounted into the manager, and a stored token would leak
+core's admin credential to an agent.
+
+The dashboard deep-links into this org — a `config repo` link
+per container row and a `commit on forge` link per approval
+card. See `docs/web-ui.md`.
+
 ### Manager view of applied + meta
 
 The manager container gets three host-side bind mounts via