fix: approval UI was never mounted; add typed confirmation for destructive

Root cause of "chat gave me no further feedback — had to go to Ops": two
compounding bugs, found by reading the actual production session transcript.

1. InlineApproval.svelte — all of last session's live-status/self-heal work —
   was never imported or rendered anywhere. Chat.svelte had its own separate,
   much dumber approval bar (no status tracking, no destructive handling, just
   silently disappears after clicking) that WAS the one users actually saw.
   Deleted the dead bar and its state; InlineApproval now renders per-message.

2. chat.ts's extractApprovals hardcoded `tool.name === 'request_execution'`,
   so any approval raised by the newer `run` tool was invisible — no card, no
   feedback, nothing to self-heal, forcing the operator to the Ops page with
   zero acknowledgement in the conversation. This was the actual proximate
   cause of last night's destroy-135 session. Fixed to match on response
   shape, not tool name, so it doesn't silently break again for the next new
   gated tool.

3. Nomos was telling operators "type something like 'I confirm destroy 135'"
   for destructive actions (SOUL.md) but no backend path ever consumed that
   phrase — chat-assent explicitly (and correctly) excludes destructive from
   loose assent, but I never built the alternative. Added
   isTypedConfirmation() (cmd/nomos/assent.go): stricter than loose assent,
   requires an explicit "confirm" statement, only applies to destructive-
   flagged pending approvals.

4. InlineApproval's completed-state hardcoded "Provisioned successfully" —
   wrong/confusing for a destroy or arbitrary `run` command. Now says
   "Completed on <target>" and shows the actual command output, verified live
   against the real destroy-135 execution.

Verified live in a real browser against the production API/DB (dev server
proxying to :8090): the historical stuck session now retroactively renders
both executions as resolved with correct wording and real output.

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

web/src/lib/stores/chat.ts

@@ -6,6 +6,7 @@ export interface PendingApproval {
   executionId: string
   action: string
   target: string
+  destructive: boolean
 }
 
 export interface ChatMessage {
@@ -18,18 +19,28 @@ export interface ChatMessage {
 
 const APPROVAL_RE = /execution\s+([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})/i
 
+// Deliberately NOT filtered by tool name. There is no fixed set of gated
+// tools — `run` can execute anything, and any future tool that queues an
+// approval should surface a card the same way. A prior version hardcoded
+// `t.name === 'request_execution'`, so approvals raised by the newer `run`
+// tool were silently invisible in chat: no card, no feedback, nothing to
+// self-heal, forcing the operator to the Ops page with zero acknowledgement
+// back in the conversation. Matching on the response shape (not the tool
+// name) is what makes this robust to new gated tools without another
+// silent breakage.
 function extractApprovals(tools: ToolCallResult[]): PendingApproval[] {
   const out: PendingApproval[] = []
   for (const t of tools) {
-    if (t.name !== 'request_execution' || t.type !== 'tool_result') continue
+    if (t.type !== 'tool_result') continue
     const text = typeof t.result === 'string' ? t.result : JSON.stringify(t.result ?? '')
     if (!text.includes('requires approval')) continue
     const m = text.match(APPROVAL_RE)
     if (m) {
       out.push({
         executionId: m[1],
-        action: t.args?.action ?? 'unknown',
-        target: t.args?.target ?? 'unknown'
+        action: t.args?.action ?? t.args?.purpose ?? t.name ?? 'unknown',
+        target: t.args?.target ?? 'unknown',
+        destructive: /\bDESTRUCTIVE\b/.test(text)
       })
     }
   }