fix: clear workflow status when an account precondition ends a run (Comfy-Org#15161)

## Summary

A runtime credits refusal leaves the workflow's execution status stuck
at `running` forever.

## Changes

- **What**: `handleAccountPreconditionError` in
`src/stores/executionStore.ts` now clears the workflow's
`workflowStatus` entry before resetting execution state.

Mechanism on `main`:

- `handleExecutionError` calls
`handleAccountPreconditionError(e.detail)` and returns early when it
returns true. These errors (`INSUFFICIENT_CREDITS` /
`WORKSPACE_INSUFFICIENT_CREDITS`, routed via
`resolveAccountPrecondition`) open their own modal and are deliberately
kept out of the error panel and error count.
- `handleAccountPreconditionError` only called
`clearInitializationByJobId` then `resetExecutionState`.
- `resetExecutionState` deletes `queuedJobs[jobId]` and the
`jobIdToWorkflow` entry, but never touches `workflowStatus`.

These are runtime errors: the job was accepted, got a machine, and
`execution_start` already wrote `running` before the refusal arrives. So
the status map keeps `running` indefinitely, and every reader of
`getWorkflowStatus` (status badges, the first-run tour result card)
promises a result that will never arrive.

`handleExecutionInterrupted` already does the right thing and is the
precedent this copies. Ordering matters: the `jobIdToWorkflow` lookup
and status clear must happen before `resetExecutionState`, which deletes
that mapping.

## Review Focus

- Clearing rather than writing `failed` is intentional and matches the
interrupt path — an account precondition is a gating state with its own
modal, not a workflow failure, so it should leave no badge.
- Sibling early-return branches (`handleServiceLevelError`,
`handleCloudValidationError`) were left alone. Service-level errors have
an existing test asserting the status stays `running`, so changing that
is a separate decision.
- Unit test added in `src/stores/executionStore.test.ts`: paid-style
credits payload after `execution_start`, asserting the status goes from
`running` to cleared. Verified it fails on `main` (`expected 'running'
to be undefined`) and passes with the fix.

Found while reviewing
Comfy-Org#15091. Distinct from
Comfy-Org#14619, which covers
the submit-time refusal where no `prompt_id` is ever issued and the
status never passes through `running` at all; this is the
accepted-then-refused runtime path.

Co-authored-by: Connor Byrne <c.byrne@comfy.org>

Author: christian-byrne

src/stores/executionStore.test.ts

@@ -936,6 +936,28 @@ describe('useExecutionStore - workflowStatus', () => {
     }
   })
 
+  it('clears running when an account precondition error ends the run', () => {
+    callStoreJob('job-1', workflowA)
+    fireExecutionStart('job-1')
+    expect(store.getWorkflowStatus(workflowA)).toBe('running')
+
+    apiEventHandlers.get('execution_error')!(
+      new CustomEvent('execution_error', {
+        detail: {
+          prompt_id: 'job-1',
+          node_id: '1',
+          node_type: 'TestNode',
+          exception_message:
+            'Payment Required: Please add credits to your account to use this node.',
+          exception_type: 'InsufficientFundsError',
+          traceback: []
+        }
+      })
+    )
+
+    expect(store.getWorkflowStatus(workflowA)).toBeUndefined()
+  })
+
   it('drops pending failed when service-level error fires before storeJob', () => {
     apiEventHandlers.get('execution_error')!(
       new CustomEvent('execution_error', {

src/stores/executionStore.ts

@@ -686,6 +686,8 @@ export const useExecutionStore = defineStore('execution', () => {
     })
     if (!precondition) return false
 
+    const workflow = jobIdToWorkflow.get(detail.prompt_id)
+    if (workflow) clearWorkflowStatus(workflow)
     clearInitializationByJobId(detail.prompt_id)
     resetExecutionState(detail.prompt_id)
     return true