docs: clarify approval row is marked failed, not absent, on flake validation failure

docs/approvals.md

@@ -28,6 +28,27 @@ 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). If either check fails, no
+   pending approval is created for the operator — the row is
+   marked failed and surfaces on the dashboard with the
+   validation message:
+   - **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