### System details

Omarchy Quattro (4.x), reproduced in a virt-manager VM. Not hardware-specific: the cause is in the prompt code itself, referenced below against the current `quattro` tree.

### What's wrong?

Clicking the update affordance in the shell opens a floating terminal whose first interaction is a `gum confirm` Yes/No. The Yes/No boxes render as buttons but ignore mouse clicks — you have to move to the keyboard mid-flow to answer a prompt you reached by clicking.

Steps:

1. Boot, and click the update notification/bar affordance (not `omarchy update` from a shell).
2. A floating terminal opens with "Ready to update?" and a Yes/No confirm.
3. Click "Yes". Nothing happens.
4. Press Enter. The update starts.

This is not a misconfiguration or a terminal problem. gum's `confirm/`, `choose/`, and `main.go` contain no mouse handling at all. Bubble Tea only receives mouse events when a program opts in with `tea.WithMouseCellMotion`, which gum never does, so the terminal is never asked to report clicks in the first place. `--show-help` is on by default, so the key hints are already visible and users still try to click, because styled Yes/No boxes read as buttons.

The prompt in question is `bin/omarchy-update-confirm:15`, and the post-update reboot prompt at `bin/omarchy-update-restart:8` has the same problem. There are 43 `gum confirm` call sites in `bin/` overall, all keyboard-only by construction.

What makes this more than a gum quirk is that every GUI entry point into a terminal prompt has the same shape: `shell/plugins/bar/widgets/SystemUpdate.qml:20` and `bin/omarchy-migrate-notify:44` both hand off through `omarchy-launch-floating-terminal-with-presentation`. The mouse works right up until the terminal opens, and then silently stops working. A prompt the user arrived at *by clicking* should be answerable by clicking.

### Suggested fix

fzf is already a runtime invariant (`install/omarchy-base.packages`) and supports this properly:

- Mouse is on by default (`--no-mouse` disables it).
- `left-click` is a bindable key, and fzf moves the cursor to the clicked row *before* dispatching the binding (`t.vset(cy)` in `src/terminal.go`), so `--bind 'left-click:accept'` is genuine single-click-to-answer rather than click-then-confirm.
- Exit codes already match gum's: 130 on Esc/Ctrl-C, same as gum's `exit.StatusAborted`.
- `--no-input` plus `pos(n)` actions give a real two-button widget with no query line, and `--height` keeps it inline instead of taking the alternate screen — which matters because `omarchy-update` runs under `script -qefc` and a fullscreen TUI would fill `/tmp/omarchy-update.log` with escape sequences.
- Colors can be read from the gum theme variables `omarchy-restart-gum` already exports (`FOREGROUND`, `BACKGROUND`, `GUM_CONFIRM_SELECTED_*`) and mapped onto fzf `--color`, so no new `default/themed/*.tpl` and no migration are needed.

I'd like to propose an `omarchy-confirm` helper along those lines, adopted first by the two update-path prompts above, leaving the other call sites for a follow-up if the approach is welcome. Happy to open a PR.