fix(first-run-tour): disarm the acceptance deadline on any reported status

`resetExecutionState` drops a job from `queuedJobs` without clearing its
workflow status, so `tourRunAccepted` can read false while the run reports
`running`. Watchers batch, so an accept-then-reset inside one tick is never
observed and the deadline stays armed against a live run.

Acceptance and status now both disarm it. A refused submission produces
neither, so #14619 stays caught.

Addresses review feedback:
#15091 (comment)

Author: Connor Byrne

src/renderer/extensions/firstRunTour/tour/useFirstRunTourController.ts

@@ -74,6 +74,7 @@ function useFirstRunTourControllerInternal() {
       executionErrorStore.hasNodeError || executionErrorStore.hasPromptError
     ],
     ([status, refused], previous) => {
+      if (status !== undefined) stopAcceptDeadline()
       if (status === 'running') runState.value = 'generating'
       else if (status === 'completed') runState.value = 'succeeded'
       else if (status === 'failed') runState.value = 'failed'
@@ -113,6 +114,10 @@ function useFirstRunTourControllerInternal() {
    * queuePrompt response rather than the socket, so this cannot pre-empt the
    * longer offline grace: a run accepted at all disarms this immediately and
    * leaves the connection question to `OFFLINE_GRACE_MS`.
+   *
+   * Acceptance is not the only disarm. `resetExecutionState` drops a job from
+   * `queuedJobs` without clearing its status, so a run can report a status
+   * while this reads false. A refusal produces neither signal.
    */
   watch(tourRunAccepted, (accepted) => {
     if (accepted) stopAcceptDeadline()