[Feature] Add stable DOM selectors (data-testid) to toolbar buttons for automated testing

## Summary

The top toolbar buttons (Queue Prompt, Queue Front, View Queue, View History, and the settings/gear control) lack stable, queryable DOM selectors. Automated UI testing (Playwright/WebDriver) cannot reliably locate and click them, timing out even though the elements exist in the DOM.

## Environment

- ComfyUI: 0.28.0
- Testing via: Playwright Chromium (headless)

## Problem

Enumerating clickable elements (`a, button, [role=button], input[type=submit], [onclick]`) finds 17 elements, but clicking the toolbar buttons fails with `Timeout 3000ms exceeded`:

- \`Queue Prompt\` (\`queue-button\`)
- \`Queue Front\` (\`queue-front-button\`)
- \`View Queue\` (\`comfy-view-queue-button\`)
- \`View History\` (\`comfy-view-history-button\`)
- settings gear (\`⚙️\`) / close (\`×\`)

Root cause appears to be one or more of:
1. Buttons are not interactive until after the JS bundle asynchronously initializes the canvas/LiteGraph (so \`DOMContentLoaded\` is too early).
2. Buttons are covered by a drawer/overlay and need a panel opened first.
3. Selectors like \`#queue-button\` don't match the rendered structure (class names rather than ids).

## Request

To make the toolbar automatable, please consider:

1. **Stable selectors** — add a \`data-testid\` (e.g. \`data-testid="queue-prompt"\`, \`data-testid="view-queue"\`) or stable \`aria-label\` to each toolbar button, independent of CSS class names that may change between builds.
2. **Readiness signal** — either ensure toolbar buttons are clickable right after \`DOMContentLoaded\` (not gated on full canvas init), or emit a custom event (e.g. \`comfy:ui-ready\`) when the toolbar is interactive, so tests can \`page.waitForFunction(() => window.comfyUiReady)\` instead of fixed sleeps.

This is specifically about the DOM toolbar buttons — the LiteGraph canvas (nodes/edges rendered on canvas/WebGL) is understood to be out of scope for DOM automation.

## Why

Downstream integrations and test suites that wrap the ComfyUI frontend (custom hosts, autotest harnesses, CI smoke tests) need deterministic selectors. Today they must rely on brittle class-name matching or timeouts, which break across releases.

Start from the ComfyUI frontend entry points that render the Queue Prompt, Queue Front, View Queue, View History, and settings/close toolbar controls; no source file or test path is named in the issue. Reproduce the timeout with Playwright Chromium, then verify the chosen stable selectors and any readiness signal after initialization, including overlay states. Done means all listed controls can be located and interacted with deterministically without fixed sleeps.

Written by the indexing model from the issue text.