feat(unic-archon-dlc): a `controls` node in `/build` writes `inert` or `can-fail` per check into `evidence.json`

What

After verification, a node that runs each mechanism check's positive control against the run's own tree in a scratch worktree, records whether the control made the check fail, and writes controls: {<check>: inert | can-fail} into evidence.json. A check with no control, or whose control does not make it fail, is inert, never a pass.

Why

Run 3 ran the four controls for 43021–43024 by hand in a session, one at a time, after the build; 43024 needed three attempts because of the documented ordering (snapshot first, then 43023, then 43024). A hand ritual rots. The register's F5 § 1 already says a mechanism can read green by construction; this is the node that proves, per run, that it did not. Pairs with the Consumer Task that puts each control's design beside its check in checks/README.md (the node reads them from there).

Evidence

• Findings register, § "G. What run 3 taught about the instrument", row G18: https://github.com/unic/unic-agents-plugins/blob/bcf688a/docs/research/2026-08-31-dlc-run-2-findings.md
• Run record and harvested artefacts: ~/Desktop/run3-parked/ on the maintainer's machine (run record § the four positive controls; register § G row G18)
• Dispatch record: #457 from comment 5698289748 down

Not decided

• Whether the node reads controls from checks/README.md (prose) or from a controls/ directory of scripts.
• Whether inert fails evidence_policy or only reports.
• Which of declaresInteractive's four branches (tabIndex, a[href], role="button", onClick) each need their own control.

Filed 2026-09-17 by wayfinder-orchestrator-10 from run 3's measurements. needs-specs: grill before dispatch.

Start by reviewing the /build verification flow, evidence.json, checks/README.md, and the dispatch record in issue #457. Resolve the listed open design questions before implementation, including the control source, inert policy, and declaresInteractive branches. Done means each mechanism control is run against the scratch worktree and the resulting controls entries are recorded per run.