fix(copilot): let the executor say when a block could first run

Review was right that entering `execute` is still too early: DAG
construction, snapshot restoration and pipeline assembly all happen inside
it and reject a malformed graph having changed nothing, so a validation
failure reported a run to resolve.

Only the executor knows where that line falls, so it reports it. A
`onBlocksMayRun` context extension fires immediately before `engine.run`
on both entry points, and execution-core records the run from there rather
than guessing at it from outside. A rejected graph now correctly says
nothing started.

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

Author: icecrasher321

apps/sim/executor/execution/executor.ts

@@ -101,6 +101,7 @@ export class DAGExecutor {
     this.registerRestoredClonedSubflows(context.subflowParentMap, restoredClonedSubflows)
 
     const engine = this.buildExecutionPipeline(context, dag, state)
+    this.contextExtensions.onBlocksMayRun?.()
     return await engine.run(triggerBlockId)
   }
 
@@ -258,6 +259,7 @@ export class DAGExecutor {
     context.subflowParentMap = this.buildSubflowParentMap(dag)
 
     const engine = this.buildExecutionPipeline(context, dag, state, filteredSnapshot)
+    this.contextExtensions.onBlocksMayRun?.()
     const result = await engine.run()
     if (result.metadata) {
       result.metadata.largeValueKeys = context.largeValueKeys

apps/sim/executor/execution/types.ts

@@ -238,6 +238,16 @@ export interface PiiBlockOutputRedaction {
 }
 
 export interface ContextExtensions {
+  /**
+   * Fired once, immediately before the engine may run a block.
+   *
+   * Everything the executor does first — DAG construction, snapshot restoration, pipeline
+   * assembly — can reject a request having changed nothing, so a caller that needs to know
+   * whether a side effect was possible cannot infer it from having called `execute`. Only
+   * the executor knows where that line falls, so it reports it rather than being guessed at
+   * from the outside.
+   */
+  onBlocksMayRun?: () => void
   workspaceId?: string
   executionId?: string
   largeValueExecutionIds?: string[]

apps/sim/lib/workflows/executor/execution-core.ts

@@ -961,6 +961,19 @@ async function executeWorkflowCoreImpl(
 
     const principalSubject = resolvePrincipalSubject(metadata.principal)
     const contextExtensions: ContextExtensions = {
+      /**
+       * The only honest answer to "could a side effect have occurred", and the executor is
+       * the only thing that knows it: everything before this — DAG construction, snapshot
+       * restoration, pipeline assembly — can reject a request having changed nothing.
+       *
+       * The logging session was the wrong proxy in both directions. `safeStart`'s result is
+       * never checked, so blocks run even when it fails, reporting that nothing started for
+       * a run that did; and it flips before trigger resolution and serialization, reporting
+       * a run for failures that never reached a block.
+       */
+      onBlocksMayRun: () => {
+        executorStarted = true
+      },
       stream: !!onStream,
       selectedOutputs,
       executionId,
@@ -1052,14 +1065,6 @@ async function executeWorkflowCoreImpl(
       contextExtensions,
     })
 
-    /**
-     * The last statement before a block can run, and therefore the only honest answer to
-     * "could a side effect have occurred". The logging session is the wrong proxy in both
-     * directions: `safeStart`'s result is never checked, so blocks execute even when it
-     * fails — reporting nothing started for a run that did — and it flips before trigger
-     * resolution and serialization, reporting a run for failures that never reached a block.
-     */
-    executorStarted = true
     const result = runFromBlock
       ? ((await executorInstance.executeFromBlock(
           workflowId,