docs: document flake.lock validation on request_apply_commit (follow-up to #434)

docs/approvals.md

@@ -28,6 +28,25 @@ 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.
+3a. **Flake validation (ApplyCommit only):** after the proposal tag
+   is planted, hive-c0re reads `proposal/<id>:flake.lock` and
+   runs two checks (closes #317). The request is rejected (no
+   approval row created) if either fails:
+   - **Stale lock** — materialises the commit in a temp worktree,
+     runs `nix flake lock` (no `--update-input` flags, so it only
+     fills missing entries), and rejects if the committed
+     `flake.lock` differs from the result. Triggered when the
+     manager added or removed `inputs` in `flake.nix` without
+     re-running `nix flake lock`. Fix: run `nix flake lock` in
+     the config repo, commit, and re-submit.
+   - **Duplicate inputs** — groups lock nodes by their canonical
+     `original` field; rejects if two or more nodes share the same
+     source. This usually means an input is missing
+     `inputs.<x>.inputs.nixpkgs.follows = "nixpkgs"`. Fix: add
+     the `follows` directive, re-lock, and re-submit.
+   Both checks only flag *new* violations — agents whose lock
+   already carried duplicates before this check was added are
+   unaffected until a coordinated config-change pass via manager.
 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