`t` opens Ghostty in $HOME, not the listing directory

On Omarchy with Ghostty as the default terminal, `t` ("terminal here") opens a window, but the shell is in `$HOME` rather than the directory omafiles is showing.

I just installed 0.0.6 from the release package. The app is great. This is the first thing that bounced.

## What I expected

A new terminal whose cwd is the current listing directory. Same idea as `omarchy-launch-terminal`, which is what `terminal_command` is modelled on.

## What happens

A Ghostty window appears. Prompt is `adam@da6:~`. `pwd` is `/home/adam`.

No error in omafiles. The spawn succeeds. The directory just does not stick.

## Environment

| | |
| --- | --- |
| omafiles | 0.0.6-1 (`pacman -U` from the v0.0.6 release) |
| Omarchy | 4.0.1-1 |
| Hyprland | 0.56.2 |
| default terminal | Ghostty 1.3.1-arch2 (`com.mitchellh.ghostty.desktop`) |
| xdg-terminal-exec | 0.14.3-1 |
| uwsm | 0.26.7-1 |
| keymap | stock, no `~/.config/omafiles/keymap.toml` |

Ghostty is already running as a single instance:

```
/usr/bin/ghostty --gtk-single-instance=true --working-directory=/home/adam
```

That `--gtk-single-instance=true` is on the desktop `Exec=` line, so every `xdg-terminal-exec` launch inherits it.

## Repro, outside the app

This is the line `crates/omafiles/src/actions.rs` builds:

```
setsid uwsm-app -- xdg-terminal-exec --dir=/tmp/omafiles-t-test
```

`xdg-terminal-exec --print-cmd --dir=/tmp/omafiles-t-test` expands to the right thing:

```
/usr/bin/ghostty
--gtk-single-instance=true
--working-directory=/tmp/omafiles-t-test
```

Running it with a Ghostty already open creates a new window titled `adam@da6:~`. The new shell's cwd is `/home/adam`, not the `--dir`. Same process pid as the existing Ghostty. `--working-directory` never reached the new window.

`open_terminal_here` in `crates/omafiles/src/main.rs` does call `actions::open_terminal(&self.current_path())`, so omafiles is handing over the listing directory. The loss happens after spawn.

## Why

Ghostty's GTK single-instance mode ignores `--working-directory` on later launches. The existing process opens a new window and keeps its original cwd, or inherits from the last focused Ghostty window. File managers hit this constantly. Two write-ups:

- https://github.com/ghostty-org/ghostty/discussions/4123 (comment: `gtk-single-instance` makes `--working-directory` follow the first instance)
- https://github.com/ghostty-org/ghostty/discussions/8043 (same with `+new-window` / single-instance)

Omarchy's own `omarchy-launch-terminal` uses the same `xdg-terminal-exec --dir=` shape, so Super+Enter can look fine when a Ghostty is already focused (inherit cwd). From omafiles the focused window is the explorer, so inherit does not save you.

## Workaround that actually lands in the directory

Giving Ghostty a command to run forces a real new process, and then `--dir` sticks. I ran:

```
setsid uwsm-app -- xdg-terminal-exec --dir=/tmp/omafiles-t-test-cmd -- zsh -c 'cd /tmp/omafiles-t-test-cmd && exec zsh'
```

New window title `adam@da6:/tmp/omafiles-t-test-cmd`. New pid. `pwd` is the test dir.

A slightly less ugly form that should be enough:

```
xdg-terminal-exec --dir="$dir" -- "$SHELL" -l
```

The other file-manager trick is `ghostty --gtk-single-instance=false --working-directory="$dir"`, which fights the desktop file. Staying on `xdg-terminal-exec` and passing a shell as the command keeps the Omarchy default-terminal indirection.

`setsid` + `uwsm-app` are fine. I would not spend time there.

## Small extra, maybe ignore

`t` always uses the listing directory (`current_path()`). `a` already special-cases a selected folder and starts the agent *inside* it. If someone has a subdirectory highlighted and hits `t`, they may expect the child. That is not what bit me here. The window I got was `$HOME`, not the parent listing. Flagging it only because the two actions already disagree about "here".