[RFC] Decompose `dialogService.ts` — extract domain-specific dialog factories

## Problem

`src/services/dialogService.ts` is 620 lines containing factory methods for every dialog type in the application: execution errors, sign-in, API key auth, subscription, cloud notifications, password updates, confirmation, prompt, top-up credits, and more.

It imports from 6+ platform directories, making it a coupling bottleneck. Adding a new dialog type requires modifying this service and potentially adding imports from new domains.

## Proposed Deepening

Keep `dialogService.ts` as a thin orchestrator with generic methods (`showDialog`, `showConfirmation`, `showPrompt`). Extract domain-specific dialog factories to their domains:

- `showExecutionErrorDialog` → `platform/execution/` (alongside the execution stores)
- `showSignInDialog`, `showApiNodesSignInDialog` → `platform/auth/`
- `showTopUpCreditsDialog`, `showSubscriptionDialog` → `platform/cloud/subscription/`
- `showCloudNotificationDialog` → `platform/cloud/notification/`
- `showUpdatePasswordDialog` → `platform/auth/`

Each domain provides a composable like `useExecutionDialogs()` that internally calls the generic `dialogStore.showDialog()`.

## Migration Plan

1. Extract one dialog domain at a time
2. `dialogService.ts` shrinks with each extraction
3. Generic dialog methods (`showConfirmation`, `showPrompt`) stay in `dialogService.ts`

## Testing Strategy

- Existing dialog tests pass
- Each domain gets focused tests for its dialog factories

┆Issue is synchronized with this [Notion page](https://www.notion.so/Issue-11059-RFC-Decompose-dialogService-ts-extract-domain-specific-dialog-factories-33e6d73d365081e0862dcc48459f03b6) by [Unito](https://www.unito.io)