fix(desktop): rename launcher to <app> so it self-loads the runtime (#35709)
Fixes https://github.com/denoland/deno/pull/35709
## Problem
`deno desktop` shipped a wrapper (a `.bat` on Windows, a shell script on
Linux) next to the backend binary, which ran `laufey_webview --runtime
<app-runtime>`. Users who ran the raw backend binary instead of the
wrapper hit a cryptic `No runtime library found`.
## Fix
laufey auto-loads a runtime library co-located with the backend binary
and sharing its base name (`LaufeyFindColocatedRuntime` →
`<exe-base>.dll`/`.so`/`.dylib`). So rename the backend binary to the
app name and drop the wrapper:
- **Windows**: `AppName.exe` + `AppName.dll` (was `AppName.bat` +
`laufey_webview.exe` + `AppName.dll`). Deep-link script + MSI Start-Menu
shortcut updated to target `AppName.exe` with no args.
- **Linux**: `AppName` + `AppName.so` (was a shell launcher + `laufey` +
`libdenort.so`). laufey resolves `<exe-base>.so` via `/proc/self/exe`,
which follows the `/usr/bin/<pkg>` → `/usr/lib/<pkg>/<app>` symlink used
by `.deb`/`.rpm`, so the wrapper's `readlink` dance is no longer needed.
The `.deb`/`.rpm` symlink and `.desktop` `Exec` already point at
`<app>`.
- **macOS**: unchanged — it already has no wrapper (the backend binary
is the bundle's `CFBundleExecutable` directly, per #35619; the runtime
resolves via the NSBundle search).
Also: this fixes runtime loading from paths with a space (`C:\Program
Files\`) since laufey resolves from its own module path, not a
`--runtime` string.
## Verification
- **Windows** (real Win11): renamed a real bundle's backend to
`<app>.exe` next to `<app>.dll` and ran it — loads the runtime, no
`.bat`/`--runtime`.
- **Linux** (real x86_64): built the laufey webview backend, renamed it
`myapp` next to `myapp.so`, ran `myapp` with no `--runtime`/env — it
resolved and loaded the co-located `myapp.so` (control with no `.so`
gives `No runtime library found`).
- Packaging unit tests updated for the new layout; `cargo test
desktop::` green.