feat: agent and CLI control plane for sessions, worktrees, and scheduled tasks (#2408)

Add a shared OpenChamber control service with two thin adapters — a native
`openchamber` tool injected into managed OpenCode, and new CLI commands — so
users can manage parallel sessions, worktrees, and scheduled tasks
conversationally through agents or from the terminal.

Control plane:
- New openchamber-control service owning a fixed action contract:
  projects.list, models.list, session list/create/send/fork/status/messages,
  and schedule list/create/run/delete/toggle. Session and worktree deletion
  and project registration are deliberately not exposed.
- New openchamber-sessions module owning create/worktree/prompt orchestration,
  Goal Mode dispatch, wait semantics (initial idle never counts as completion;
  timeout and cancellation are failures), and explicit partial-failure results.
- Scheduled-task logic extracted into a service shared by routes, CLI, and the
  agent tool.

Agent tool:
- Managed OpenCode gets a materialized plugin registering one typed tool with
  a loopback-only callback, per-child ephemeral bearer (timing-safe, never
  persisted or logged), and abort propagation into the service.
- The ~1.5k-token schema applies progressive disclosure: short descriptions,
  server-side validation returning actionable usage errors, and intent
  guardrails — created sessions/tasks are user-facing work (not age
  self-delegation); worktree/goal/agent/variant/wait are omit-by-default;
  dispatches produce no completion notification, and later result r
  to session.messages, which now returns the authoritative sessionStatus.
- session.create without a user-named model picks from favorites/re
  send/fork omit the selection and the service reuses the target session's
  last user-message model, agent, and variant before falling back t
- An "Agent control tool" setting (default on, Save + Reload to apply)
  disables plugin injection entirely.

CLI:
- New `openchamber session`, `schedule`, `projects`, and `models` commands
  with automatic instance targeting, --wait/--timeout/--last-assist
  worktree flags, and Goal Mode, preserving interactive, non-TTY, --quiet,
  and --json contracts. The control HTTP timeout derives from the w
  instead of the 4-second default.

UI:
- New built-in "Schedule a Task" starter (/schedule-task) running a
  dialogue that defines a task and offers to create it via the tool after
  explicit confirmation; Craft a Goal and Feature Planning gain the
  handoff offer, and guided starters reserve the question tool for concrete
  option choices. Localized in all 10 locales, migrated into custom
  starter lists, hidden on VS Code.
- Sidebar shows CLI/agent-created sessions live via the control eve
- openchamber tool calls render with per-action titles and metadata.

packages/web/server/lib/session-goal/DOCUMENTATION.md

@@ -66,8 +66,9 @@ before touching the filesystem). Rationale: metadata rides every
 - UI display fetches content via the GET route
   (`useGoalObjectiveContent`); in VS Code the route is unavailable, so the
   strip degrades to the audit note (display-only fallback by design).
-- Scheduled goal tasks write the file server-side directly via
-  `objectives.js`.
+- Server-created goals write the file through `create.js`, which also owns
+  objective fitting, inline fallback, metadata creation, and the synthetic
+  first-turn reminder shared by scheduled tasks and CLI-created sessions.
 
 ## Flow
 
@@ -174,6 +175,24 @@ stamp `metadata.openchamber.goal` onto the fresh session (objective = the
 expanded task prompt) and attach the goal-mode intro part to the prompt.
 The loop here picks it up from session events like any other goal.
 
+## CLI-created goals
+
+`openchamber session create --prompt <text> --goal` uses the explicit
+`POST /api/openchamber/sessions` orchestration route. The server creates the
+session, fits and stores the expanded prompt as its objective, patches active
+goal metadata, appends the synthetic goal reminder, and only then dispatches
+the prompt. `--goal-token-budget` applies the same optional budget contract as
+scheduled goals. Slash commands retain command dispatch semantics and cannot
+carry the synthetic prompt part; the goal metadata is still installed before
+the command runs.
+
+`openchamber session send --goal` and `openchamber session fork --goal` use
+the same server-owned prompt orchestration. Send installs a fresh goal on the
+target session; fork first uses the official OpenCode fork operation (at the
+optional message boundary), then installs the goal on the new session. Both
+preserve the objective-file-before-metadata and metadata-before-dispatch
+ordering used by create and scheduled goals.
+
 ## Limitations
 
 - Web-server feature: VS Code (extension-only) renders goal state via