Splash logo wave animation imperceptible on fast/cached loads (no minimum display time)

## Problem / Goal
QA (Denys, 1.47 RC re-test on https://frontend-rc.testenvs.comfy.org/) reported the Comfy logo animation is not visible on the login/loading screen.

**This is not a regression and not a deploy/asset issue.** Filing as a low-priority UX tracking item so the perceived-missing animation has a home and product/design can decide whether to change it.

The animated login/loading logo is the pre-Vue splash loader inlined in `index.html` (`#splash-loader`, z-9999) — a pure-CSS keyframe animation (`splash-rise` 4s + `splash-wave` 1.2s) over an inline SVG wave-fill mask. In `main` since #9516 (inlined by #9849).

Served-build check against the RC:
- Fetched the live RC HTML; `#splash-loader` and all keyframes (`wave-group`, `wave-path`, `splash-rise`, `splash-wave`) are present.
- The splash CSS block is **byte-identical** to `origin/main` (1275 chars). The animation code is present and correct in the deployed build.

Root cause of the perceived absence: the splash is removed the instant the first Vue view mounts — `CloudLayoutView.vue` (login/onboarding) and `UserSelectView.vue` call `document.getElementById('splash-loader')?.remove()` in `onMounted`; `App.vue` removes it when the workspace spinner clears. On a fast/warm/cached load the view mounts within a few hundred ms, before the 4s `splash-rise` has visibly filled the logo (the mask starts empty at `translateY(280px)` and fills as it rises). The user sees only a brief faint outline. It is also disabled outright under OS `prefers-reduced-motion: reduce`. This behavior is identical on prod and RC and is independent of the 1.47 changes.

## Proposed Solution
Give the splash a minimum on-screen duration so at least one visible fill cycle plays before it is torn down. Options:
- Track a `splashShownAt` timestamp when the loader is first painted and defer `#splash-loader` removal until `max(0, MIN_MS - elapsed)` (e.g. `MIN_MS ≈ 800`), applied consistently across the three removal sites (`App.vue`, `CloudLayoutView.vue`, `UserSelectView.vue`).
- Or gate removal on the first `animationiteration`/short timeout.
- Or decide this is working-as-intended and close.

## Acceptance Criteria
- [ ] On a fast/warm/cached load of the login/loading screen, the splash logo shows a visibly animating (rising/waving) fill for a perceptible minimum duration before removal.
- [ ] `prefers-reduced-motion: reduce` still short-circuits the animation (static logo) and is unaffected.
- [ ] Removal remains consistent across `App.vue`, `CloudLayoutView.vue`, and `UserSelectView.vue` (no double-remove errors, no lingering splash after mount).
- [ ] No added perceptible delay to time-to-interactive beyond the chosen minimum splash window.

_Filed from 1.47 RC QA triage. Not a 1.47 regression; served animation code matches `main` exactly._

Start with the inlined #splash-loader and keyframes in index.html, then trace the removal calls in App.vue, CloudLayoutView.vue, and UserSelectView.vue. Exercise fast, warm, or cached login/loading paths while checking prefers-reduced-motion behavior. Done means a visibly animating splash remains for the chosen minimum duration, removal stays consistent, and no lingering loader or unacceptable time-to-interactive delay remains.

Written by the indexing model from the issue text.