fix(concurrency): scope assent/destructive windows to session, not just agent

Fix 1 of plans/2026-07-11-concurrent-task-execution.md — the safety-critical
one. The assent window (and destructive window) were keyed purely by agent
id ("assent_window.agent:<uuid>"). With one agent:nomos entity serving every
concurrent task, this meant approving Task A's plan opened a window that ANY
concurrently-running task's config-mutation/destructive actions could also
ride, auto-executing without their own approval.

- store.go / agent.go: assentWindowActive/openAssentWindow and
  destructiveWindowActive/openDestructiveWindow/destructiveWindowKey all gain
  a sessionID parameter; keys become
  "assent_window.agent:<id>.session:<sessionID>" and
  "destructive_window.agent:<id>.target:<slug>.session:<sessionID>". Missing
  session id fails closed (no window) rather than falling back to the old
  agent-wide key.
- continue.go: the auto-continuation worker's window check moved from once-
  per-batch to once-per-pending-item, scoped to that item's own session —
  it was previously checking ONE agent-wide window for a batch that can span
  multiple tasks.
- agent.go tool-dispatch: injects `_session_id` into a COPY of the wire args
  sent to the MCP server (never into the args used for the emitted/logged/
  persisted tool call, and never part of any tool's declared InputSchema —
  invisible to the model) so the gating checks on the OTHER side of the
  process boundary know which task is asking.
- internal/mcp/server.go: assentWindowActive/destructiveWindowActive/
  classifyAndGate gain the same sessionID parameter, read from
  args["_session_id"] at the three call sites (request_execution's
  apt_upgrade/pct_create branches, and the shared classifyAndGate used by
  restart/pct_exec/systemctl/run).

Verified against the live stack with the exact scenario from the plan: opened
an assent window for session A only, then called `run` with an identical
config-mutation command for session A (window open) and session B (same
agent, no window). A auto-ran (execution status completed); B correctly
queued for approval (pending_approval) instead of bleeding through — proven
at both the MCP response text and the executions table.

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

cmd/nomos/continue.go

@@ -57,13 +57,15 @@ func (a *agent) runContinuationWorker(ctx context.Context) {
 
 func (a *agent) processContinuations(ctx context.Context) {
 	pending := a.store.pendingContinuations(ctx, 5)
-	windowOpen := a.store.assentWindowActive(ctx, a.agentID)
 	for _, p := range pending {
-		// Scope gate: only auto-continue while an approved plan is active.
-		// A finished one-off execution with no window is left as-is (marked
-		// continued so we don't re-check it forever) — the operator decides
-		// what happens next, as today.
-		if !windowOpen {
+		// Scope gate: only auto-continue while an approved plan is active FOR
+		// THIS SESSION. Checked per-item, not once for the whole batch — with
+		// multiple tasks in flight, one task's open window must never cover a
+		// pending continuation belonging to a different task.
+		if !a.store.assentWindowActive(ctx, a.agentID, p.SessionID) {
+			// A finished one-off execution with no window is left as-is
+			// (marked continued so we don't re-check it forever) — the
+			// operator decides what happens next, as today.
 			a.store.markContinued(ctx, p.ExecID)
 			continue
 		}