feat: session goals - server-driven goal loop with independent small-model audit (#2148)

Arm the target button in the composer and the next prompt becomes a goal:
the server keeps the session working toward it (idle tick -> small-model
audit -> continuation) until the objective is verifiably complete, blocked,
or out of budget — even with the UI closed.

Server (packages/web/server/lib/session-goal):
- event-driven loop on the global SSE hub; goal state lives in
  session.metadata.openchamber.goal (merge-safe patches, stale-write guard
  by goal id), so it survives restarts and syncs to every client for free
- the small-model audit (objective + last assistant turn only, language
  pinned to the objective) is the sole termination authority; blocked needs
  3 consecutive verdicts, audit outages tolerate one unaudited continuation
  then stop the goal as resumable-blocked
- hard stops: optional token budget, auto-continuation cap (Resume grants a
  fresh allowance), turn errors; user abort pauses the goal instead of
  blocking it, and resuming over an aborted tail nudges immediately
- token accounting as a snapshot of the latest turn (input + cache.read +
  output), goal-relative via a creation baseline and segmented across
  compactions; a compaction summary skips the audit and continues
- continuations reuse the session's own provider/model/agent/variant

UI:
- three-mode target button (arm / disarm / manage dialog), informational
  goal strip with inline pause/resume and an Evaluating indicator, sidebar
  state glyph, objective length counter (2000-char server clamp),
  read-only completed goals
- goal entry points: composer (sessions and drafts), start-new-session-
  from-answer dialog, plan implement dialog (plan content becomes the
  objective), scheduled tasks (Run as goal + budget)
- Settings -> Chat -> Goal: feature toggle + default token budget with
  three-layer parity (web server, client persistence, VS Code bridge);
  VS Code renders goal state but hides the entry points (the loop runs in
  the web server only)

Notifications: per-turn "ready" notifications are suppressed while a goal
is active; settling sends one final notification (desktop, web-push, APNs
generic titles with the session name as body) honoring the completion
toggle. Error/question/permission notifications are untouched.

Docs: user guide (session-goals) in all 9 locales + sidebar entry,
scheduled-tasks cross-reference, server module DOCUMENTATION.md.

packages/ui/src/lib/messages/executionMeta.ts

@@ -15,6 +15,17 @@ export const EXECUTION_FORK_DEFAULT_INSTRUCTIONS =
     "if it is a conclusion or summary, your task is to verify it, explain whether you agree or disagree, and correct it if needed. " +
     "Always clearly state what you understand your task to be, and wait for the user's approval of your conclusions before taking any further actions.";
 
+// Assertive variant prefilled when "Run as goal" is checked: the new session
+// must treat the forked message as an assignment and execute it to completion
+// (the goal loop audits progress and keeps it going), not report back and wait.
+export const EXECUTION_FORK_GOAL_INSTRUCTIONS =
+    "The message I share is an assignment handed over from another AI agent. Extract the concrete task from it and start executing immediately: " +
+    "if it is an implementation plan, implement that plan; " +
+    "if it is a conclusion or summary, verify it against the actual current state of the code and correct it if needed; " +
+    "if it is a bug description, find the root cause and fix it. " +
+    "Do not stop at restating your understanding and do not wait for approval — keep working until the task is verifiably complete, " +
+    "and end every turn with a factual statement of what is done, what was verified, and what remains.";
+
 // Fixed connective that opens the forked assistant content. Not editable by the
 // user — it sits between the user's instructions and the assistant message.
 const EXECUTION_FORK_CONTENT_PREFACE =