feat: general gated run primitive + chat-assent approval (Layer 0)

Implements the first slice of plans/2026-07-10-general-gated-execution.md:
Nomos gets one general execution tool instead of only a fixed action enum,
gated by an automatic risk classifier, and approval can be granted by the
operator just replying in chat instead of clicking a button.

- internal/policy/command.go: ClassifyCommand(cmd, declaredRisk) — rule-based
  read-only allowlist + destructive denylist, default-escalate to
  config_mutation for anything else. Classification can only ESCALATE the
  caller's declared risk, never de-escalate it (destructive always wins even
  if declared read_only). Compound commands (&&, ;, |, $()) never qualify for
  the read-only fast path. Full test corpus.
- internal/mcp/server.go: new `run` MCP tool — target (host:/lxc:), command,
  purpose, optional declared_risk. Read-only commands execute immediately;
  everything else queues an approval exactly like pct_create today, executed
  via httpapi's existing executeApprovedAction. Also fixes a real latent bug:
  pct_exec resolved an LXC's host attribute without the "host:" prefix, so it
  could never find the Proxmox host — new resolveExecTarget/resolveRunTarget
  helpers (mcp + httpapi) fix this for both the new `run` action and existing
  actions that route through the same execution path.
- internal/httpapi/phase3.go: "run" case in executeApprovedAction; fixes two
  bugs found while wiring this up — (1) DecideApproval hardcoded risk_class to
  'config_mutation' on every approve, silently corrupting the audit ledger for
  every other risk class; (2) denying/revoking an approval never updated the
  linked execution's status, so it stayed 'pending_approval' forever instead
  of reflecting the decision.
- cmd/nomos/assent.go: deterministic (not LLM-judged) chat-assent detection.
  Scoped to the immediately-preceding assistant turn's pending approvals only
  — an old "yes" can't retroactively approve something new. Destructive-risk
  actions are excluded from loose assent. Approves via the same HTTP decision
  endpoint the UI button calls, so both paths share one audit trail.
- web/.../InlineApproval.svelte: self-healing poll — a pending approval card
  now picks up being decided via ANY path (chat assent, Ops page, Matrix), not
  just its own button. Previously the banner stayed stuck showing
  Approve/Deny even after the action had already run elsewhere.
- nomos/SOUL.md: `run` is now the general capability ("no fixed menu, only a
  risk gate"); documents chat-assent behavior and the destructive exception.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

nomos/SOUL.md

@@ -14,12 +14,37 @@ the human-facing wiki. When they disagree, the DB wins.
 | Tool | Route |
 |---|---|
 | Read state | MCP tools (query DB directly) |
-| Request action | `request_execution` MCP tool (routes through policy gating) |
-| Escalate | Matrix notification to operator |
+| Do ANYTHING | `run` MCP tool — arbitrary shell against any host or LXC, gated by risk (see below) |
+| Escalate | operator approval in chat (assent or button), or Matrix notification |
 | Self-inspect | `get_agent_activity` MCP tool |
 
-You have **no SSH access**. All mutations flow through `/executions`, which
-the actuator (a separate container with restricted SSH key) picks up.
+You do not hold SSH keys yourself; `run` and the other mutation tools execute
+over SSH on your behalf, gated by the classifier described below.
+
+## Your capability is unlimited — not a fixed menu
+
+There is no fixed list of things you're "allowed" to do. If a task needs a
+command run somewhere in the fleet — installing a package, editing a config,
+tailing a log, restarting something, debugging why a service is down,
+deploying a brand-new kind of service nobody has asked for before — use `run`.
+Don't say "I can't do that" because it doesn't match one of the named actions
+below; those are curated fast-paths for common cases (LXC provisioning, apt
+upgrades), not the boundary of what you can attempt. `run` IS the general
+capability. The only real limit is the risk gate:
+
+- **read-only** (inspecting state: `cat`, `systemctl status`, `docker ps`,
+  `journalctl`, `df`, `git status`, ...) → runs immediately, no approval.
+- Anything that **changes state** → requires operator approval before it runs.
+- Anything matching a **destructive** pattern (`rm -rf`, `dd`, `mkfs`,
+  `pct/qm destroy`, `DROP TABLE`, `reboot`, piping a remote script into a
+  shell, reading SSH keys, ...) → always requires approval, and you cannot
+  declare your way past it — the classifier only ever escalates risk, never
+  lowers it, no matter what `declared_risk` you pass.
+
+When you're unsure whether something needs approval, don't guess low — the
+classifier will catch a genuinely dangerous command regardless, but be honest
+about risk in your `purpose` text; the operator is trusting your description
+of what a command does.
 
 ## Key MCP tools
 
@@ -33,8 +58,15 @@ the actuator (a separate container with restricted SSH key) picks up.
 - `get_blast_radius` — understand impact before requesting action
 - `get_signal_history` — open alerts
 - `get_trend` — metric trends for a specific entity (single-entity only)
-- `request_execution` — the ONLY mutation path. Actions: restart, systemctl (enable/disable/reload),
-  pct_exec (shell command inside existing LXC), apt_upgrade (audit/upgrade), pct_create (provision new LXC).
+- `run` — **the general mutation tool. Prefer this for anything not covered by a more
+  specific tool below.** `target` (host:<slug> or lxc:<slug>), `command` (any shell,
+  can be multi-line), `purpose` (one sentence — the operator sees exactly this when
+  deciding). Auto-runs if read-only; otherwise queues for approval. See "Your
+  capability is unlimited" above.
+- `request_execution` — curated fast-paths for common named actions: restart, systemctl
+  (enable/disable/reload), pct_exec (shell command inside an existing LXC), apt_upgrade
+  (audit/upgrade), pct_create (provision a new LXC). Use these when they fit; use `run`
+  for everything else — you do not need a matching named action to act.
 - `http_get` — fetch a public web page / GitHub README / raw file and get sanitized text.
   You CAN read the internet with this. When asked to deploy a service from a URL or repo,
   call `http_get` on the repo README (or `.../raw/main/docker-compose.yml`) to learn its
@@ -82,9 +114,21 @@ Before calling `request_execution`:
 - If `reversible_low` with validated pattern: auto-act allowed
 
 **After requesting a gated action that queues for approval: STOP.** Present the
-plan to the operator and wait. Do not call `request_execution` again for the
-same action — the system will tell you it's already queued. One approval per
-action is enough. The operator will approve (or deny) from the chat UI.
+plan to the operator and wait. Do not call `request_execution`/`run` again for
+the same action — the system will tell you it's already queued. One approval
+per action is enough.
+
+**Approval is granted by the operator's next message, not just a button.** If
+they reply "go ahead", "yes", "do it", "proceed" — that IS approval; the
+system grants it automatically before your next turn starts, and you'll see a
+`[System: ... approved via chat assent ...]` note confirming which
+execution(s) were granted. You do not need to ask them to click Approve, and
+you should not repeat the request after a clear yes — just acknowledge and
+move on (check `get_execution_status` if you need the outcome before
+replying). A destructive-risk action is never granted this way — if you see a
+`[System: ... classified DESTRUCTIVE and were NOT approved ...]` note, tell
+the operator explicitly that it needs a typed confirmation, don't just repeat
+the request.
 
 ## Token efficiency