feat(menu): pikr Bluetooth device picker

[junjitree]

krypt menu bluetooth is the odd one out on the bar. It launches bluetui in a
floating alacritty, so it is not a picker, it stacks a new window per click
(no lock, no debounce), and it needed a config file of its own just to close on
Esc. .menu-wifi already solved the same shape of problem — list, pick,
connect, forget — in pikr. This ports Bluetooth to that model.

How it works

Reads are one busctl GetManagedObjects snapshot per refresh, shaped by jq;
bash only splits on tab. Connect, disconnect, forget and power are busctl
calls, and each is verified by re-reading the property rather than trusting the
exit status — "already connected" and "in progress" are errors whose outcome is
success. Only scanning and pairing need bluetoothctl, because both need a
process that stays alive: discovery belongs to the D-Bus client that asked for
it, and an agent lives only as long as its process.

Devices and actions are separate lists. The actions are keys, named in the
prompt, using bluetui's letters where pikr leaves them free — ^S scan, ^O
power; bluetui's u for unpair is pikr's clear-line, so forget is Right, as
in .menu-wifi. A pikr without --kb-custom has no keys to name, so there the
device list carries a row through to an actions list instead; the script probes
pikr --help rather than assuming.

Pairing

Worth calling out, because it was not obvious. bluetoothctl --agent X pair in
its one-shot form asks bluez to pair before its own agent is registered, so
bluez falls back to NoInputNoOutput and negotiates No Bonding — a key
that is never persisted. AirPods Pro reported Paired: yes, played audio, and
dropped to Paired: no seconds later, repeatably. An HCI trace showed our
Pair Device carrying Capability: NoInputNoOutput where bluetui's carried
KeyboardDisplay. The agent session is now driven over a named pipe, and the
pairing waits for bluez to confirm the default agent before asking.

Anything needing a passkey or a PIN still hands off to bluetui with a
notification; bluetui stays in deps.toml as that fallback.

Verification

Stub harness (fake busctl, bluetoothctl, pikr, notify-send on PATH
with canned D-Bus JSON): 137 assertions, 0 failing, and every guard was
broken once to confirm its test goes red. shellcheck -x clean at default
severity with zero directives; mode 100755.

On real hardware (AirPods Pro 2, Keychron K8): pairing, bonding, forgetting and
reconnecting, confirmed both in /var/lib/bluetooth and in an HCI trace.
The power toggle and the forget-list path are covered by the harness but have
not been run on a live adapter.

Deliberate trade-off

With a pikr that can bind the keys, a mouse reaches connect and disconnect
and nothing else — pikr makes only a row clickable, so a mouse route to the
actions means either action rows in the device list or a second binding on the
bar icon, and both were rejected here. This is a known departure from "mouse
and keyboard, both work, always"; the reasoning and what would have to give to
revisit it are written up in docs/backlog.md, along with the rest of what is
not covered.