### System details

Intel i9-9880H, Intel UHD 630 + NVIDIA Quadro T2000 Mobile, Omarchy 4.0.4-1, mise-bin 2026.9.12-1

### What's wrong?

A wrapper generated by `omarchy-mise-install` can call itself forever. It never exits, and it pins a CPU core by running `mise use -g` about twice a second in the same PID. On my machine a background service's `claude --version` ran for 19 hours this way before I noticed the fans.

**Cause.** The generated wrapper ends with:

```bash
exec mise x "<package>" -- "<bin>" "$@"
```

`mise x` is expected to put the tool's install dir first in `PATH`, so `<bin>` resolves to the real binary. But when mise's **shims** dir is also on `PATH`, `mise x` leaves the `PATH` order as it is. If `~/.local/bin` comes first, `<bin>` resolves back to the wrapper, which execs itself in the same PID, runs `mise use -g` again, and repeats with no end.

Login shells don't hit this, because `mise activate` puts the install dirs first. It does hit processes that get a `PATH` snapshot with `~/.local/bin` early and the shims later. The case I hit was a systemd user unit whose `Environment=PATH=` was captured at install time.

**Steps to reproduce**

```bash
M=$HOME/.local/share/mise
PATH="$HOME/.local/bin:$(dirname "$(mise which codex)"):$M/shims:/usr/bin" \
  timeout 5 codex --version; echo "rc=$?"    # rc=124 (hangs)

# The same PATH without the shims dir works:
PATH="$HOME/.local/bin:$(dirname "$(mise which codex)"):/usr/bin" \
  timeout 5 codex --version; echo "rc=$?"    # rc=0
```

Of my installed wrappers, `claude`, `codex`, `gh`, `grok` and `opencode` loop under that kind of `PATH`.

**Suggested fix.** Resolve the binary to an absolute path before exec, so the wrapper can never find itself. In the `omarchy-mise-install` heredoc:

```bash
mise use -g --quiet $package_arg || exit 1
bin_path=\$(mise which --tool $package_arg $bin_arg) || exit 1
exec mise x $package_arg -- "\$bin_path" "\$@"
```

I tested this with `codex` under the looping `PATH` above: it prints the version and exits 0. The existing migrations that recognize the wrapper format would need to learn the new form. Optional hardening: exit if `bin_path` is the wrapper itself (`[ "$bin_path" -ef "$0" ]`), so a future resolution bug fails fast instead of spinning.