docs(webapp): update agent guidance for the v3 engine removal

Refresh the CLAUDE.md / AGENTS.md / legacy-v3-code rule sections that described
the now-deleted V1 files, and drop stale comment references to removed modules.

Author: ericallam

AGENTS.md

@@ -140,9 +140,9 @@ User API call -> Webapp routes -> Services -> RunEngine -> Redis Queue -> Superv
 - **internal-packages/schedule-engine**: Durable cron scheduling
 - **internal-packages/zod-worker**: Graphile-worker wrapper (DEPRECATED - use redis-worker)
 
-### Legacy V1 Engine Code
+### v3 (engine V1) removed
 
-The `apps/webapp/app/v3/` directory name is misleading - most code there is actively used by V2. Only specific files are V1-only legacy (MarQS queue, triggerTaskV1, cancelTaskRunV1, etc.). See `apps/webapp/CLAUDE.md` for the exact list. When you encounter V1/V2 branching in services, only modify V2 code paths. All new work uses Run Engine 2.0 (`@internal/run-engine`) and redis-worker.
+v3 (engine V1: MarQS + Graphile worker) is end-of-life and its execution code has been removed. The `apps/webapp/app/v3/` directory name is historical - everything there now serves V2 (Run Engine 2.0, `@internal/run-engine` + redis-worker). There is no V1 execution path: a `RunEngineVersion` `V1` branch only rejects gracefully so v3 clients get a clean 4xx, never a 5xx. Do not reintroduce V1. See `apps/webapp/CLAUDE.md` and `.claude/rules/legacy-v3-code.md`.
 
 ### Documentation
 

apps/webapp/CLAUDE.md

@@ -98,17 +98,9 @@ Do NOT add new jobs using zodworker/graphile-worker (legacy).
 - Socket.io: `app/v3/handleSocketIo.server.ts`, `app/v3/handleWebsockets.server.ts`
 - Electric SQL: Powers real-time data sync for the dashboard
 
-## Legacy V1 Code
+## v3 (engine V1) removed
 
-The `app/v3/` directory name is misleading - most code is actively used by V2. Only these specific files are V1-only legacy:
-- `app/v3/marqs/` (old MarQS queue system)
-- `app/v3/legacyRunEngineWorker.server.ts`
-- `app/v3/services/triggerTaskV1.server.ts`
-- `app/v3/services/cancelTaskRunV1.server.ts`
-- `app/v3/authenticatedSocketConnection.server.ts`
-- `app/v3/sharedSocketConnection.ts`
-
-Some services (e.g., `cancelTaskRun.server.ts`, `batchTriggerV3.server.ts`) branch on `RunEngineVersion` to support both V1 and V2. When editing these, only modify V2 code paths.
+v3 (engine V1: MarQS + Graphile worker) is end-of-life and its execution code is gone. The `app/v3/` directory name is historical; everything under it now serves V2. There is no V1 execution path: a `RunEngineVersion` `V1` branch (e.g. in `triggerTask.server.ts`, `cancelTaskRun.server.ts`) only rejects/finalizes gracefully so v3 clients get a clean 4xx, never a 5xx. Do not reintroduce V1. See `.claude/rules/legacy-v3-code.md` for the deprecation boundary.
 
 ## Performance: Trigger Hot Path
 

apps/webapp/app/v3/mollifierDrainerWorker.server.ts

@@ -26,12 +26,9 @@ declare global {
  *      factory) guarantees a signal landing during boot can never find
  *      the polling loop running without a graceful-stop path.
  *
- * The drainer is intentionally NOT wired through `~/services/worker.server`
- * — that file is the legacy ZodWorker / graphile-worker setup. The
- * mollifier drainer is a custom polling loop over `MollifierBuffer`, not
- * a graphile-worker job, so it gets its own lifecycle file alongside the
- * redis-worker workers (`commonWorker`, `alertsWorker`,
- * `batchTriggerWorker`).
+ * The mollifier drainer is a custom polling loop over `MollifierBuffer`, not a
+ * redis-worker job, so it gets its own lifecycle file alongside the redis-worker
+ * workers (`commonWorker`, `alertsWorker`, `batchTriggerWorker`).
  *
  * Gating order:
  *   - `TRIGGER_MOLLIFIER_DRAINER_ENABLED !== "1"`  → early return. Unset defaults

apps/webapp/app/v3/services/batchTriggerV3.server.ts

@@ -86,9 +86,8 @@ type RunItemData = {
  * we increment the BatchTaskRun's completed count. Once the completed count is equal to the expected count, and the
  * batch is sealed, we can consider the batch completed.
  *
- * So now when the v3 batch is considered completed, we will enqueue the ResumeBatchRunService to resume the dependent
- * task attempt if there is one. This is in contrast to v2 batches where every time a task was completed, we would schedule
- * the ResumeBatchRunService to check if the batch was completed and set it to completed if it was.
+ * When the v3 batch is considered completed it is marked COMPLETED. (Dependent-attempt
+ * batches from batchTriggerAndWait only existed on the retired V1 engine.)
  *
  * We've also introduced a new column "resumedAt" that will be set when the batch is resumed. Previously in v2 batches, the status == "COMPLETED" was overloaded
  * to mean that the batch was completed and resumed. Now we have a separate column to track when the batch was resumed (and to make sure it's only resumed once).