Add AMD ROCm GPU option to the desktop installer
## What changed
- Add an AMD GPU choice to the installer picker with updated recommended
badge logic, logo asset, and i18n copy.
- Accept and auto-select the new `amd` device type in the install flow
when it is detected.
- Update `@comfyorg/comfyui-electron-types` and lockfile entries
required for the new device enum.
## Why
- Desktop users with AMD GPUs need a first-class install path instead of
falling back to CPU/manual options.
- This reuses the existing picker/device model to keep the change scoped
and consistent with current UX.
- Tradeoffs: torch mirror selection still falls back to the CPU mirror
for AMD until a dedicated ROCm mirror is available.
## Evidence
- Interactive Storybook file
`apps/desktop-ui/src/components/install/GpuPicker.stories.ts`
<img width="1377" height="834" alt="image"
src="https://github.com/user-attachments/assets/34145f46-d8cc-4e59-b587-0ab5ee79f888"
/>
## Summary
Extracts desktop UI into apps/desktop-ui package with minimal changes.
## Changes
- **What**:
- Separates desktop-specific code into standalone package with
independent Vite config, router, and i18n
- Drastically simplifies the main app router by removing all desktop
routes
- Adds a some code duplication, most due to the existing design
- Some duplication can be refactored to be *simpler* on either side - no
need to split things by `isElectron()`
- Rudimentary storybook support has been added
- **Breaking**: Stacked PR for publishing must be merged before this PR
makes it to stable core (but publishing _could_ be done manually)
- #5915
- **Dependencies**: Takes full advantage of pnpm catalog. No additional
dependencies added.
## Review Focus
- Should be no changes to normal frontend operation
- Scripts added to root package.json are acceptable
- The duplication in this PR is copied as is, wherever possible. Any
corrections or fix-ups beyond the scope of simply migrating the
functionality as-is, can be addressed in later PRs. That said, if any
changes are made, it instantly becomes more difficult to separate the
duplicated code out into a shared utility.
- Tracking issue to address concerns: #5925
### i18n
Fixing i18n is out of scope for this PR. It is a larger task that we
should consider carefully and implement properly. Attempting to isolate
the desktop i18n and duplicate the _current_ localisation scripts would
be wasted energy.
