Controllable window app_id for dev windows (dx serve --app-id)

## Feature Request

I develop Dioxus desktop apps on a tiling window manager (Hyprland). During development I relaunch the app constantly, and every relaunch is a new native toplevel window. On a tiling WM the layout shifts each time that window appears, so I want to pin the dev window to a fixed spot (a floating slot or a dedicated special workspace) with a window rule.

The problem is the handle. Hyprland routes windows by their Wayland `app_id` (X11 `WM_CLASS`). A Dioxus desktop window inherits the executable name, and there is no way to set the `app_id` yourself. So the only rule I can write is keyed on each project's binary name: I have to edit my WM config for every app I work on, and I cannot write a single rule that matches any Dioxus dev window.

I want to keep running the real native window and watch how it actually behaves, so rendering the app a different way in dev is not what I am after. I just need the window to carry an identity I choose, so the WM can place it.

Concretely, I would like to set the `app_id` from the dev tooling, without touching app code:
```
dx serve --app-id my-dev-window
```
and/or a field in `Dioxus.toml`.

## Implement Suggestion

tao (used by `dioxus-desktop`) already has `EventLoopBuilderExtUnix::with_app_id` (tauri-apps/tao#912), so this is about surfacing it in the dev flow rather than adding it from scratch.

What is missing today:

- `dioxus-desktop` never calls `with_app_id`, so the desktop window always falls back to the executable name.
- `dx serve` has no flag for it, and nothing reads such a value.

A possible shape:

1. `dx serve` accepts `--app-id ` (and/or a `Dioxus.toml` field) and passes it to the launched app through an env var. If unset, it could default to the `[bundle] identifier` already present in `Dioxus.toml`.
2. `dioxus-desktop` reads that env var when building the event loop and calls `EventLoopBuilder::with_app_id(...)` on Linux.

One caveat to handle: a GTK application id carries single-instance semantics, and there is a known crash when multiple processes share one id (tauri-apps/tao#1186). The desktop side should avoid registering as a single-instance GtkApplication, and the relaunch cycle should be tested on Wayland.

Start by tracing the dx serve launch flow and the dioxus-desktop event-loop setup, then review Tao's EventLoopBuilderExtUnix::with_app_id and the relevant Dioxus.toml configuration. Verify the chosen identity reaches the native window without app code changes, preserves the existing fallback when unset, avoids conflicting GTK single-instance behavior, and survives repeated relaunches on Wayland.

Written by the indexing model from the issue text.