### What happened

Removing an app via the Omarchy menu (Remove → App) deletes the `.desktop` launcher of a shell plugin but leaves the plugin itself installed, enabled and running. The removal reports success, so it looks like the app is gone while its service keeps running and its bar widget stays in place.

Hit this with a third-party plugin ([omamail](https://github.com/huacnlee/omamail)), but nothing about it is specific to that plugin — it applies to any shell plugin that ships a `.desktop` file to claim a URL scheme or MIME type.

### Why it happens

`bin/omarchy-remove-launcher-entry` classifies the launcher into one of five cases: web app, TUI, user-owned `.desktop`, pacman-owned, flatpak. A plugin-owned launcher in `~/.local/share/applications` matches the third case, whose handler is just an `rm`:

```bash
if is_user_desktop_file; then
  display_name="${entry_name:-$desktop_name}"
  rm -f "$desktop_file"
  update-desktop-database "${desktop_file%/*}" &>/dev/null || true
  exit 0
fi
```

Nothing checks whether a plugin under `~/.config/omarchy/plugins/` owns that launcher, so `omarchy-plugin-remove` is never reached.

### Steps to reproduce

1. Install any shell plugin that registers a `.desktop` handler in `~/.local/share/applications`. (Concrete case: omamail, whose `install-mailto.sh` writes `omamail.desktop` claiming `x-scheme-handler/mailto` and sets it as the default.)
2. Open the Omarchy menu → Remove → App, pick the plugin's entry.
3. The removal reports success and the entry disappears from the launcher.

### Expected

The plugin is removed — or, at minimum, the command declines and points at `omarchy plugin remove <id>` rather than silently deleting only the launcher.

### Actual

Only the `.desktop` file is deleted. Left behind:

- `~/.config/omarchy/plugins/<id>/` — still on disk
- the plugin's entry in `shell.json`'s bar layout
- the plugin registry entry, still `"enabled": true` (`omarchy-shell shell listPlugins`)
- the plugin's service, still running — its cache files kept getting written days after the "removal"
- `~/.config/mimeapps.list`, still holding `x-scheme-handler/mailto=<id>.desktop`, now pointing at a file that no longer exists

That last one is the part with a visible blast radius beyond the plugin: the MIME default is left dangling, so `mailto:` links silently fall through to a different handler with no indication why.

`omarchy plugin remove <id>` is the command that actually works here — it disables the plugin in the shell, drops it from the bar layout and rescans. It leaves `~/.config/<id>` and the mimeapps entry, but those are arguably the plugin's own business.

### Possible fix

Before the `is_user_desktop_file` branch, check whether the launcher's `Exec`/`Icon` path resolves inside `~/.config/omarchy/plugins/`, and if so delegate to `omarchy-plugin-remove` the same way the webapp and TUI branches delegate to their own removers. Clearing any `mimeapps.list` defaults that name the deleted `.desktop` would also stop the dangling-handler part, and looks useful for the plain user-`.desktop` case too.

### System details

Intel i5-10310U, Intel UHD Graphics (CometLake-U GT2), Omarchy 4.0.2-1, kernel 7.1.9-arch1-2.

Verified the same code path is present in `main` at the time of filing, not just in the 4.0.2 package. Happy to attach an `omarchy debug` log if it would help, though the bug is visible from the script alone.