dashboard: diff against applied/proposal/<id>, prefer fetched_sha

approval_diff now runs git diff refs/heads/main..refs/tags/
proposal/<id> against the applied repo instead of cobbling a
single-file diff from proposed. consequences: multi-file
proposals show every change, manager amendments in proposed
cannot lie about what'll be deployed, no-op proposals render
an explicit '(proposal matches currently-deployed tree)'.
displayed sha prefers fetched_sha (hive-c0re-vouched) and
falls back to commit_ref only for the brief pre-fetch window.
unified_diff helper + similar dep dropped — git diff is the
source of truth now. dead-code allows on the lifecycle git
helpers + approvals.set_fetched_sha come off since all are
wired up. readme picks up the tag flow + /applied RO mount.

README.md

@@ -26,7 +26,8 @@ host (NixOS, runs hive-c0re.service)
 └── nixos-containers  (each bind-mounts its socket dir → /run/hive,
    │                   credentials dir → /root/.claude,
    │                   durable notes dir → /state;
-   │                   manager additionally gets /agents RW)
+   │                   manager additionally gets /agents RW
+   │                   + /applied RO for the deployed-tag mirror)
    │
    ├── hm1nd      hive-m1nd serve : claude turn loop +
    │              MCP (send / recv / request_spawn / kill / start /
@@ -52,10 +53,22 @@ auto-scroll with "↓ N new" pill; event history backfilled on page
 load; collapsible inbox + collapsible journald viewer + collapsible
 `agent.nix` viewer per agent on the dashboard.
 
-Config changes flow the other way: manager edits `/agents/<name>/config/agent.nix`
-(bind-mounted from the host's proposed repo) → commits → submits the sha as
-an approval → operator clicks ◆ APPR0VE on the dashboard → hive-c0re copies
-the file into the applied repo and `nixos-container update`s the agent.
+Config changes flow the other way: manager edits files under
+`/agents/<name>/config/` (`agent.nix` is the entry point, but arbitrary
+sibling files in the commit are preserved) → commits → submits the sha
+via `request_apply_commit`. Hive-c0re immediately fetches that commit
+from the proposed repo into the applied repo and pins it as
+`proposal/<id>` — from this moment the proposal is immutable from the
+manager's side. Operator clicks ◆ APPR0VE on the dashboard → hive-c0re
+moves the working tree to the proposal, runs `nixos-container update`,
+and either fast-forwards `applied/main` (tagging `deployed/<id>`) or
+annotates `failed/<id>` with the build error and rolls back to the
+previous deployed tree. Denials leave a `denied/<id>` annotated tag
+carrying the operator's note. The manager sees everything that
+shipped (or didn't) via a read-only `/applied/<n>/.git` mirror inside
+its container; `git show applied/deployed/<id>` etc. is the audit
+trail. See [`docs/approvals.md`](docs/approvals.md) for the full tag
+state machine.
 For decisions the manager needs human signal on, `ask_operator(question,
 options?, multi?)` queues a free-text/checkbox/radio form on the
 dashboard; the answer arrives later as a `HelperEvent::OperatorAnswered`