## System details

- Omarchy: 4.0.3-1
- Kernel: 7.2.3-arch1-3
- BlueZ / bluez-utils: 5.87-2
- bluez-tools: 0.2.0-6
- Hardware: Lenovo ThinkPad T480, Intel Wireless 8265/8275 Bluetooth adapter
- Device: older Apple Bluetooth HID keyboard (`LegacyPairing: yes`, modalias `usb:v05ACp0256d0050`)

## What's wrong?

The Omarchy Bluetooth panel cannot complete pairing with a legacy Bluetooth keyboard that requires a PIN exchange. The panel may briefly show the keyboard as connected, but it never becomes a Linux input device and typing produces no input.

The stock user service registers this agent:

```ini
ExecStart=/usr/bin/bt-agent -c NoInputNoOutput
```

During the failed panel pairing, the journal records:

```text
bluetoothd: src/agent.c:display_pincode_reply() Agent replied with an error: org.bluez.Error.Rejected, Passkey does not match
```

The panel invokes `omarchy bluetooth device pair <address>`. The installed `omarchy-bluetooth-device` implementation discards the pairing output and ignores failure:

```bash
timeout 20s bluetoothctl pair "$address" >/dev/null 2>&1 || true
trust_device
timeout 20s bluetoothctl connect "$address" >/dev/null 2>&1 || true
```

Consequently, there is nowhere to display a generated PIN or request a PIN from the user, authentication failures are hidden, and the script continues into trust/connect even when pairing did not complete.

## Steps to reproduce

1. Start with an older Bluetooth keyboard for which `bluetoothctl info` reports `LegacyPairing: yes`.
2. Put the keyboard in pairing mode.
3. Open the Omarchy Bluetooth panel and select the keyboard.
4. Observe that it may briefly appear connected, but keystrokes do not work.
5. Check `/proc/bus/input/devices`; the Bluetooth keyboard is absent.
6. Check the journal; BlueZ reports that the passkey does not match.

## Expected behavior

When a Bluetooth device requires authentication, the Omarchy UI should:

- display a generated PIN that must be typed on the keyboard;
- allow the user to enter or confirm a PIN when BlueZ requests one;
- wait for pairing to finish before attempting trust/connect;
- surface authentication failures instead of silently ignoring them.

## Confirmed workaround

Pairing succeeds after stopping the stock `NoInputNoOutput` agent and using an interactive `bluetoothctl` agent. The working flow required entering a chosen PIN in `bluetoothctl`, then typing the same PIN followed by Return on the Apple keyboard. After that, the keyboard appeared as a HID input device and worked normally.

## Likely affected code

- `default/systemd/user/bt-agent.service`
- `bin/omarchy-bluetooth-device`
- `shell/plugins/panels/bluetooth/Panel.qml`

This is distinct from, but may be exacerbated by, the continuous-discovery behavior reported in #8614.