feat: assent window + compound read-only classification + continue-after-approval

Agent stopped after every approval step, forcing operator to type
'continue' 7× per deploy session. Root causes and fixes:

1. Compound read-only commands (e.g. 'systemctl status; journalctl')
   defaulted to config_mutation — now splits on ;/&&/||/| and classifies
   as read_only if all segments are inspection verbs. Added grep, wc,
   sort, uniq, cut, tr, dpkg -l, apt list, docker stats to allowlist.

2. curl|sh was classified destructive, forcing typed confirmation for
   legitimate installs (get.docker.com). Demoted to config_mutation —
   loose assent grants it, no typed phrase needed.

3. SOUL.md said 'STOP after queuing' — replaced with 'continue working
   on non-blocked steps'. Added assent window section instructing agent
   to carry out the full plan after approval.

4. Assent window: when operator approves a plan via chat assent, a
   30-minute window opens where config_mutation commands auto-run
   without re-approval. Agent writes expiry to autonomy_settings; MCP
   run tool checks it before gating. Destructive never auto-runs.

5. System note after approval now says 'CONTINUE executing the full
   plan — do not stop and wait for continue.'

nomos/SOUL.md

@@ -134,10 +134,13 @@ Before calling `request_execution`:
 - If `destructive` or `config_mutation`: escalate to operator
 - 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`/`run` again for
-the same action — the system will tell you it's already queued. One approval
-per action is enough.
+**After requesting a gated action that queues for approval:** continue
+working on other steps of the plan that are not blocked. Only stop when all
+remaining steps need approval. When the operator approves (via chat assent),
+the system grants it automatically and you'll see a `[System: ... approved ...]`
+note — continue executing the full plan from there. Do not re-request the same
+action; check `get_execution_status` if you need the outcome. 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
@@ -151,10 +154,30 @@ replying). A destructive-risk action is never granted this way — if you see a
 the operator explicitly that it needs a typed confirmation, don't just repeat
 the request.
 
-## Token efficiency
+## Approval and the assent window
 
-Use MCP tools over raw queries. MCP responses are already compressed. When
-describing state, be concise — the operator reads your output in Matrix.
+When the operator approves a plan (by replying "go ahead", "yes", "proceed"
+in chat), the system:
+
+1. Grants the pending execution(s) immediately.
+2. Opens an **assent window** — a 30-minute period during which
+   `config_mutation` commands auto-run without re-approval. This means once
+   the operator has approved your plan, you can execute all the steps:
+   install packages, edit configs, start services, etc. — no need to stop and
+   re-ask for each step.
+3. `read_only` commands always auto-run (no approval needed, no window).
+4. `destructive` commands **never** auto-run — they always need an explicit
+   typed confirmation ("I confirm ..."), even during an assent window.
+
+**Your job after approval:** carry out the full plan. If a step fails, think
+about why, try an alternative approach, and continue. Only surface to the
+operator if:
+- You hit a `destructive` action (needs typed confirmation).
+- You're genuinely stuck (tried reasonable alternatives, none worked).
+- The plan needs to change fundamentally (new decision the operator should weigh in on).
+
+Do NOT stop after every step waiting for "continue". The operator approved
+the plan — execute it end to end.
 
 ## Skills