hermes - 💡(How to fix) Fix Proposal: per-board approval policy override (scope approvals.mode per kanban board)

Title: Proposal: per-board approval policy override (scope approvals.mode per kanban board)

Summary

Approval strictness (approvals.mode: manual / smart / off) is currently global. With multi-board kanban, different boards often warrant different strictness — e.g. a trusted internal automation board running off/smart while a board touching production stays manual. I'd like to float a design for a per-board override before writing the PR, since it touches the approval gate.

Motivation

Boards are already isolated units of work (own DB, workspaces, dispatcher context, and HERMES_KANBAN_BOARD pinning). Approval strictness is the one policy that can't yet follow that boundary, so users must pick a single global mode for unrelated workstreams.

Proposed approach (working branch exists, not yet a PR)

Floating this as an issue first because it modifies the approval/security gate:

• Boards carry an optional approval_mode in their existing board.json (validated to manual / smart / off; empty clears → inherit global).
• The gate (tools/approval.check_all_command_guards) resolves an effective mode: per-board override keyed by the worker's own HERMES_KANBAN_BOARD, else the global approvals.mode.
• No cross-board bleed by construction — each worker reads only its own board's metadata. Contexts with no board (CLI/interactive, the gateway main process) fall through to global unchanged, so default behavior is identical.
• The unconditional hardline/sudo floors that sit above the mode check are untouched — a board cannot weaken those.
• CLI: boards create --approval-mode, boards set-approval-mode <slug> [mode], surfaced in boards show.

Security considerations (the reason this is issue-first)

This is additive and inert without an explicit per-board override, but it does let a board set off. Questions I'd want maintainer guidance on:

1. Should a board be allowed to set a mode stricter than global only, or also looser (off)? (My branch allows looser, matching how global off works today.)
2. Where should approval_mode live — board.json (current) vs. the main approvals config keyed by board?
3. Any concern with resolution via HERMES_KANBAN_BOARD env vs. an explicit board handle threaded through the gate?

If accepted

When this goes to PR, board-scoped tests in tests/tools/test_approval.py are mandatory (override applies on its board; does not bleed; no-board-env falls through to global; hardline floor still fires) — I'll include them as the evidence for an approval-gate change, not as an afterthought.

Happy to align on the design here first.