### System details

- CPU: Intel Core i7-1255U
- Omarchy: 4.0.0-1
- Architecture: x86_64
- Kernel: 7.1.8-arch1-3
- Quickshell package: quickshell-git 0.3.0.r20.g28771c7-2
- Qt runtime: 6.11.2
- Qt base package: qt6-base 6.11.2-2
- Qt QML package: qt6-declarative 6.11.2-1
- Qt Wayland package: qt6-wayland 6.11.2-1
- BlueZ (`bluetoothctl`): 5.87
- `bluez-tools`: 0.2.0-6
- Device: Logitech MX Mechanical Mini
- BlueZ device name: `MX MCHNCL M`

### What's wrong?

_Note: Before upgrading to Quattro, this behavior did not use to occur. The bluetooth panel (opened from the Omarchy menu) managed to display passkeys properly._

The Omarchy Bluetooth panel cannot pair a device that requires the user to type a displayed passkey.

When I tried to pair my keyboard (Logitech MX Mechanical Mini) through the panel, the panel did not show the six-digit passkey. The device state repeatedly changed between paired and connected, but the keyboard did not become usable.

After I completed pairing manually with an interactive `bluetoothctl` `KeyboardDisplay` agent, the panel stopped changing states and the keyboard worked correctly.

### Steps to reproduce

1. Use an unpaired device that requires a displayed passkey, like the aforementioned keyboard model
2. Put it into pairing mode.
3. Click the bluetooth widget in the Quickshell-based status bar to open the Bluetooth panel.
4. Select the device and start pairing.
5. Observe that the panel does not show a passkey.
6. Observe that pairing does not complete.

### Expected result

The panel must show the numeric passkey.

The user types that passkey on the Bluetooth device and (optionally) presses Enter. Pairing then completes, and the device becomes paired, bonded, trusted, and connected.

### Actual result

The panel does not show the passkey. The user cannot complete the keyboard authentication.

During the failed panel attempts, the user service journal contained this prompt:

```text
Aug 26 09:24:42 <hostname> bt-agent[1184]: Authorize this device pairing (yes/no)? Device: MX MCHNCL M (XX:XX:XX:XX:XX:XX)
```

This prompt was only present in the journal. It was not shown in the panel, and the panel did not provide a way to answer it.

### Successful control test

A normal scan found the keyboard. A forced LE scan was not necessary:

```text
[bluetoothctl]> scan on
SetDiscoveryFilter success
Discovery started
[NEW] Device XX:XX:XX:XX:XX:XX MX MCHNCL M
```

Interactive pairing with a `KeyboardDisplay` agent showed the required passkey:

```text
[bluetoothctl]> pair XX:XX:XX:XX:XX:XX
Attempting to pair with XX:XX:XX:XX:XX:XX
[CHG] Device XX:XX:XX:XX:XX:XX Connected: yes
[agent] Passkey: [123456]
[CHG] Device XX:XX:XX:XX:XX:XX Paired: yes
Pairing successful
```

After I typed the passkey on the MX keyboard and pressed Enter, pairing completed successfully.

The final device state was:

```text
Name: MX MCHNCL M
Alias: MX MCHNCL M
Paired: yes
Bonded: yes
Trusted: yes
Connected: yes
WakeAllowed: yes
```

This result shows that the keyboard, Bluetooth controller, normal scanning, BlueZ, and authentication method work correctly.

### Pairing-agent status

`bt-agent` is installed:

```text
$ command -v bt-agent
/usr/bin/bt-agent
```

The user service is active:

```text
bt-agent.service - Bluetooth pairing agent (auto-accept)
Loaded: loaded (/usr/lib/systemd/user/bt-agent.service; enabled; preset: enabled)
Active: active (running)
Main PID: 1184 (bt-agent)
└─1184 /usr/bin/bt-agent -c NoInputNoOutput
```

Therefore, this system does not have the missing `/usr/bin/bt-agent` failure reported in #6992.

### Technical evidence

`bin/omarchy-bluetooth-device` runs the pairing operation as a detached `bluetoothctl` command. It redirects standard output and errors to `/dev/null` and ignores command failures.

`shell/plugins/panels/bluetooth/Panel.qml` starts this helper as a detached process. The panel does not receive the command output, exit status, passkey, or authorization request.

The active default agent uses `NoInputNoOutput`. It cannot provide the user-facing passkey interaction that the keyboard requires.

The current panel path therefore has no user-facing BlueZ authentication flow for devices that require a displayed passkey.

A fix must:

- Start or register a suitable BlueZ pairing agent.
- Transfer authentication requests to the Quickshell panel.
- Show numeric passkeys.
- Support confirmation and text-input requests where necessary.
- Show pairing failures and timeouts.
- Clear the pending state after success, failure, cancellation, or timeout.

### Additional information

I could not produce a reliable screen recording after the manual fix. Once the valid bond existed, the panel worked correctly and no longer changed repeatedly between paired and connected.

I did not remove the working bond only to reproduce the visual loop again.