test(run-ops split): pin splitEnabled in the cross-boundary waitpoint-token test

The "control-plane-resident standalone token is found when the run-ops
replica does not hold it" case relied on the ambient RUN_OPS_SPLIT_ENABLED
env being on. Locally .env sets it (plus distinct TASK_RUN_* URLs) so the
resolver fans out new->legacy and finds the cuid-shaped token. In CI those
vars are unset, so resolveWaitpointThroughReadThrough falls back to
isSplitEnabled() -> false -> single-DB passthrough, which reads only the
run-ops replica (prisma17), never the control-plane legacy replica (prisma14)
that holds the token. The read returned null and the assertion
"expected null not to be null" failed on CI shard 3.

Inject deps.splitEnabled: true (mirroring the sibling read-gate test) so the
fan-out is exercised deterministically regardless of ambient env. Test-only;
preserves exactly what the case verifies (legacy fallback finds a
control-plane token the new replica lacks).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: d-cs

apps/webapp/app/v3/runOpsMigration/waitpointTokenResolve.server.test.ts

@@ -71,6 +71,11 @@ describe("public wait-token resolution across the split boundary", () => {
             where: { id: waitpointId, environmentId: environment.id },
           }),
         deps: {
+          // Pin split-on explicitly: without it the fan-out gate falls back to the
+          // ambient RUN_OPS_SPLIT_ENABLED env, which is unset in CI (single-DB
+          // passthrough reads only the run-ops replica and never fans out to the
+          // control-plane legacy replica that holds this cuid-shaped token).
+          splitEnabled: true,
           newClient: prisma17 as unknown as PrismaReplicaClient,
           legacyReplica: prisma14 as unknown as PrismaReplicaClient,
         },