fix(webapp): allow JWT auth on POST /api/v1/sessions

The route was secret-key-only by design ("Customer's server owns session creation"). That holds for the customer browser path — `chat.createStartSessionAction` runs server-side and authorizes there. But the cli-v3 MCP `start_agent_chat` tool is itself a server-side surface (developer's CLI/IDE acting as their own server) and only holds a JWT minted from the user's PAT. Without JWT support here it can't create sessions, blocking the entire MCP agent toolkit.

Add `allowJWT: true` and an `authorization` block requiring the `write:sessions` (or `admin`) super-scope. Resource scoping by `taskIdentifier` isn't possible at auth-resolve time — action routes don't pass `body` to the resource callback, and the task name only lives in the body — so the resource is a `sessions` wildcard and the super-scope does the gating. The JWT-issuer (cli-v3 MCP, customer servers wrapping a wider auth helper, etc.) decides which scopes to mint, which is where per-task narrowing lives.

Verified end-to-end: `mcp__trigger__start_agent_chat` → `send_agent_message("pong")` → `send_agent_message("echo")` → `close_agent_chat` all succeed against local. Two assistant turns reuse the same runId (continuation in the idle window).

Author: ericallam

apps/webapp/app/routes/api.v1.sessions.ts

@@ -96,13 +96,31 @@ const { action } = createActionApiRoute(
     body: CreateSessionRequestBody,
     method: "POST",
     maxContentLength: 1024 * 32, // 32KB — metadata is the only thing that grows
-    // Secret-key only. Customer's server (typically wrapping
+    // Customer's server (typically wrapping
     // `chat.createStartSessionAction`) owns session creation so any
     // authorization decision (per-user/plan/quota) sits server-side
     // alongside whatever DB write the customer pairs with the create.
     // The session-scoped PAT returned in the response body is what the
     // browser uses thereafter against `.in/append`, `.out` SSE,
     // `end-and-continue`, etc.
+    //
+    // JWT is allowed when the caller holds an explicit `write:sessions` /
+    // `admin` super-scope plus a `tasks:<taskIdentifier>` scope — gates
+    // server-side surfaces like the cli-v3 MCP from creating sessions on
+    // behalf of the developer without weakening the browser model.
+    allowJWT: true,
+    authorization: {
+      // Resource scoping by `taskIdentifier` isn't possible at auth-resolve
+      // time — action routes don't pass `body` to the resource callback,
+      // and the task name only lives in the body. We require a `sessions`
+      // resource scope (wildcard) and rely on `write:sessions` / `admin`
+      // super-scopes to gate access. Per-task narrowing happens implicitly
+      // because the JWT-issuer (e.g. cli-v3 MCP) decides which scopes to
+      // request when minting the token.
+      action: "write",
+      resource: () => ({ sessions: "*" }),
+      superScopes: ["write:sessions", "admin"],
+    },
     corsStrategy: "all",
   },
   async ({ authentication, body }) => {