Raise the e2e execution rate cap above other scenarios' usage

The e2e worker's per-org hourly cap of 3 was low enough that ordinary
scenarios (toolkits-mcp, no-auth-connection, connect-handoff) tripped the
backstop mid-test once the suite ran them against the shared worker. Lift
it to 20 (still exhaustible by the backstop scenario) and move the value
into one shared constant consumed by both the boot env and the test.

Author: RhysSullivan

e2e/cloud/mcp-execution-limits.test.ts

@@ -22,6 +22,7 @@ import {
 } from "../../apps/cloud/src/engine/execution-limit-messages";
 import { scenario } from "../src/scenario";
 import { Autumn, Billing, Mcp, Target } from "../src/services";
+import { E2E_EXECUTION_RATE_LIMIT } from "../setup/execution-limits";
 import type { Identity } from "../src/target";
 
 const emailOf = (identity: Identity): string => identity.credentials?.email ?? identity.label;
@@ -38,8 +39,9 @@ const orgIdOf = (bearer: string): string => {
 
 // The e2e worker is booted with a small EXECUTION_RATE_LIMIT_PER_HOUR so the
 // backstop is reachable with real executions (cloud.boot.ts). The prod cap of
-// 1000/hour can't be. Kept in sync with that env value.
-const RATE_LIMIT = 3;
+// 1000/hour can't be. One shared constant (setup/execution-limits.ts) keeps
+// this and the boot env from drifting apart.
+const RATE_LIMIT = E2E_EXECUTION_RATE_LIMIT;
 
 scenario(
   "Billing · an org out of executions is blocked before the code ever runs",

e2e/setup/cloud.boot.ts

@@ -12,6 +12,7 @@ import { createEmulator } from "@executor-js/emulate";
 
 import { bootProcesses, waitForHttp } from "./boot";
 import { AUTUMN_PLAN_SEED } from "./autumn-plans";
+import { E2E_EXECUTION_RATE_LIMIT } from "./execution-limits";
 
 export const cloudDir = fileURLToPath(new URL("../../apps/cloud/", import.meta.url));
 
@@ -92,9 +93,10 @@ export const bootCloud = async (options: CloudBootOptions): Promise<CloudBooted>
     ALLOW_LOCAL_NETWORK: "true",
     // Shrink the per-org hourly execution cap (prod default 1000) to a number
     // the rate-limit-backstop scenario can actually exhaust with real
-    // executions. Reaches the worker via CLOUDFLARE_INCLUDE_PROCESS_ENV, same
-    // as ALLOW_LOCAL_NETWORK.
-    EXECUTION_RATE_LIMIT_PER_HOUR: "3",
+    // executions — but see execution-limits.ts: it must stay above every other
+    // scenario's per-org execute count. Reaches the worker via
+    // CLOUDFLARE_INCLUDE_PROCESS_ENV, same as ALLOW_LOCAL_NETWORK.
+    EXECUTION_RATE_LIMIT_PER_HOUR: String(E2E_EXECUTION_RATE_LIMIT),
     // Throwaway PGlite on its own port + dir so it never fights `bun dev`.
     DEV_DB_PORT: String(options.dbPort),
     DEV_DB_PATH: dbPath,

e2e/setup/execution-limits.ts

@@ -0,0 +1,14 @@
+// The e2e worker's per-org hourly execution cap (EXECUTION_RATE_LIMIT_PER_HOUR).
+// One constant with two consumers, the boot recipe env (cloud.boot.ts) and the
+// rate-limit backstop scenario (cloud/mcp-execution-limits.test.ts), so they
+// cannot drift apart.
+//
+// Picking the value is a squeeze from both sides. It must be LOW enough that
+// the backstop scenario can exhaust it with real sequential executions (prod's
+// 1000/hour cannot be reached in a test), and HIGH enough that no other
+// scenario trips it: the counter is per organization and every `execute` a
+// scenario runs counts against its org, so this must exceed the busiest
+// single-org scenario's execute count (currently toolkits-mcp at ~8) with
+// comfortable headroom. If a scenario ever fails with the rate-limit backstop
+// message, it outgrew this cap: raise it here, never in the boot env alone.
+export const E2E_EXECUTION_RATE_LIMIT = 20;