Enter on a text file does nothing: xdg-open waits on nvim

Enter on `/home/adam/Downloads/README.md` looks like a no-op. No window, no status-bar error. Same for other `.md` files I tried.

This is on the same Omarchy box as #3.

## What I expected

The file to open in something I can actually use. On this machine that would be Emacs, which is the editor Omarchy has recorded as the default (`~/.local/state/omarchy/defaults/editor`). Markdown also has Typora and Omawrite registered.

## What happens

Enter runs. Nothing appears. omafiles stays quiet.

## Why

`open_with_system` in `crates/omafiles/src/main.rs` calls `actions::open_path`, which is `xdg-open` and **waits for it to exit**. That wait is deliberate, so a failure can show in the status bar. It is also what makes this one look dead.

`xdg-open` on this desktop does:

```
file --brief --dereference --mime-type README.md -> text/plain
lookup text/plain -> nvim.desktop
nvim.desktop has Terminal=true, Exec=nvim %F
```

So it starts nvim in a terminal and sits there until nvim quits. I ran `xdg-open` on the file from a shell and it hung in LazyVim, swapfile and all. Timeout 2s, still sitting in nvim. omafiles does the same wait on its background executor, so Enter never "finishes" and never reports.

Two more cuts on the same wire:

1. Ghostty is the terminal `xdg-open` would use for `Terminal=true`. With `--gtk-single-instance=true` that TUI window often never shows. Same mechanism as #3. From omafiles, you get the hang *and* no editor.

2. `file(1)` types every `.md` I tried as `text/plain`. GIO says `text/markdown` (`gio info` on the same README). The markdown handlers (Typora, Omawrite) never get a look in, because `xdg-open` is not using GIO.

Omarchy already has the script for this. `omarchy-launch-editor` wraps nvim/helix/etc with `omarchy-launch-tui`, and for Emacs it does `setsid uwsm-app -- emacs `. It also reads the user's chosen editor, which here is Emacs, not nvim. `t` / `a` / share already go through Omarchy scripts. Open-with is the one that went straight to `xdg-open`.

## Environment

| | |
| --- | --- |
| omafiles | 0.0.6-1 |
| Omarchy | 4.0.1-1 |
| Hyprland | 0.56.2 |
| default terminal | Ghostty 1.3.1, gtk-single-instance |
| Omarchy default editor | emacs |
| xdg-open for text/plain | nvim.desktop (`Terminal=true`) |
| xdg-open for text/markdown | typora.desktop (never reached) |

`~/.config/mimeapps.list` has `text/plain=helix.desktop`, but the actual desktop file is `Helix.desktop`. That id does not resolve, so it falls through to nvim.

## Repro

1. On Omarchy with Ghostty already open, put a `README.md` somewhere.
2. In omafiles, cursor it, press Enter.
3. Nothing.

Outside the app:

```
xdg-mime query filetype /home/adam/Downloads/README.md # text/plain
gio info ... | grep content-type # text/markdown
timeout 2 xdg-open /home/adam/Downloads/README.md # hangs in nvim, exit 124
```

`omarchy-launch-editor /home/adam/Downloads/README.md` does start Emacs.

## What I'd try

Keep `xdg-open` for images, PDFs, folders, the stuff that actually is a GUI app.

For the case `xdg-open` would pick a `Terminal=true` desktop file, or for anything `omarchy-launch-editor` would handle, use that script instead and do not wait on the editor. A TUI editor exiting is not "open failed".

If you want to stay on `xdg-open` for everything, at least do not wait when the handler is `Terminal=true`. Right now a hung nvim is indistinguishable from Enter doing nothing.

`gio open` would have sent this README to Typora. I am not sure that is better than the Omarchy editor, but it is how GNOME file managers type `.md`. Worth knowing `xdg-open` and GIO disagree here.

Start in crates/omafiles/src/main.rs at open_with_system and follow its call to actions::open_path/xdg-open. Reproduce with a README.md on Omarchy using the listed xdg-mime, gio info, and timeout xdg-open commands, then compare with omarchy-launch-editor. Done means pressing Enter on the markdown file no longer appears to hang and opens via an appropriate editor path.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.