refactor: derive execution state reactively from job/queue state instead of imperative reconciliation helpers

## Context

Identified as a follow-up during review of PR #12067 (fix: clear active job on reconnect if no longer in queue).

## Background

PR #12067 introduced an imperative helper `clearActiveJobIfStale(activeJobIds: Set)` in `src/stores/executionStore.ts` that is called on WebSocket reconnect to clear a stale `activeJobId` not present in the server's queue snapshot. Similarly, `reconcileInitializingJobs(activeJobIds)` follows the same imperative reconciliation pattern.

During review, @christian-byrne raised that a better long-term approach would be to use a `watch` or, ideally, to partially derive execution state from reactive job/queue state (in addition to other server data), rather than relying on imperative reconciliation functions and manual indirection.

@pythongosssss agreed this is the right direction but noted it is out of scope for the focused reconnect fix in PR #12067.

## Problem

The current design in `src/stores/executionStore.ts` requires callers to:
1. Fetch fresh queue state from the server.
2. Build a `Set` of active IDs.
3. Imperatively call `clearActiveJobIfStale(activeJobIds)` or `reconcileInitializingJobs(activeJobIds)`.

This means execution state (e.g. `activeJobId`) can drift from queue/job state unless every relevant trigger (reconnect, queue poll, etc.) correctly wires up the reconciliation call. A reactive or derived approach would keep the two in sync automatically.

## Proposed Work

- Evaluate replacing (or supplementing) the imperative `clearActiveJobIfStale` and `reconcileInitializingJobs` patterns with a `watch`-based or computed-derived approach that keeps `activeJobId` and `initializingJobIds` aligned with the live job/queue state from `queueStore`.
- Ideally, `activeJobId` (and related state like `initializingJobIds`) would be partially derived from reactive job/queue state, making stale-state scenarios impossible by design rather than patched on reconnect.
- Consider the interaction with WebSocket event-driven updates (execution_start, execution_success, etc.) and whether the reactive model can coexist with or subsume those handlers.

## References

- PR: https://github.com/Comfy-Org/ComfyUI_frontend/pull/12067
- Review comment: https://github.com/Comfy-Org/ComfyUI_frontend/pull/12067#discussion_r3215703741
- Requested by: @pythongosssss

┆Issue is synchronized with this [Notion page](https://www.notion.so/Issue-12124-refactor-derive-execution-state-reactively-from-job-queue-state-instead-of-imperativ-35d6d73d3650816096f4e259d90e8d14) by [Unito](https://www.unito.io)