bluetooth: show per-peripheral battery for split devices (ZMK)

[dwright134]

Description

Split keyboards (ZMK Corne and similar) report the battery level of each half
separately, but the Bluetooth detail view only ever showed one number.

The cause is that BlueZ's org.bluez.Battery1 interface — which
Quickshell.Bluetooth's BluetoothDevice.battery wraps — exposes a single
percentage per device. A split keyboard is one bonded device: the central half
holds the radio and relays the peripheral half's charge as an additional
GATT Battery Service (0x180F) on the same device object. BlueZ folds only one
of those into Battery1, so the second half was invisible.

This PR reads the extra 0x2A19 (Battery Level) characteristics directly over
D-Bus and surfaces them:

• BluetoothService gains a peripheralBatteries map (keyed by device
  address) populated by a small sh/busctl Process. It walks the GATT tree
  of each connected device and emits one address|percent|label line per
  Battery Level characteristic that carries a 0x2901 user-description
  descriptor — which is exactly how ZMK tags peripheral batteries (e.g.
  "Peripheral 0"). The label is read verbatim from that descriptor, so it
  generalizes to N peripherals (Peripheral 0, Peripheral 1, …) and to
  multiple keyboards.
• BluetoothDetail renders one extra entry per peripheral next to the
  existing battery text via a Repeater.

Design notes:

• Purely additive. The central battery is deliberately skipped (it's
  already covered by Battery1/device.battery), so non-split devices render
  exactly as before — peripheralBatteriesFor() returns [] for them.
• Association is structural, not heuristic. Every battery lives under the
  same /org/bluez/.../dev_XXX object path, so peripherals attach to the right
  device by construction — there is no name-matching that could go wrong.
• Survives sleep. A split half drops its BLE link when idle; a live
  ReadValue then fails fast with "Not connected", so the reader falls back to
  BlueZ's cached Value (last known level) and best-effort StartNotify to keep
  that cache warm. Every busctl call is bounded with --timeout=5.
• Refreshes on shell start, on connected changes, and every 120 s (guarded so
  runs can't overlap).

Type of change

• New feature (non-breaking change that adds functionality)

Related issues

Screenshots / video

Bluetooth detail row for a ZMK Corne, before → after:

• Before: Connected • 90%

• After:

Checklist

• My code follows the conventions in CONTRIBUTING.md (sh -c + busctl,
  matching existing Process usage in this service)
• I have tested my changes locally (live on DMS v1.4.6 with a real ZMK Corne;
  central 90% + peripheral 83% render, clean shell reload, no QML warnings)
• New user-facing strings: none new to translate — the format mirrors the
  existing (untranslated) battery/signal text ("• " + value + "%"); the
  label text comes from the device's own GATT descriptor
• Go changes: n/a (QML-only)
• QML changes: ran make lint-qml — please run in CI/devshell; my local Qt's
  qmllint couldn't parse pragma ComponentBehavior: Bound (bailed at line 2)
  so I could not get a clean local run
• dlx-docs PR: happy to add docs if you'd like this documented

[dwright134]

Pushed a follow-up fix (b59462f): the split-peripheral battery label was read from BlueZ's cached Value first, but busctl prints ay 0 for an empty byte array, so the [ -n "$lv" ] guard never fell back to ReadValue. On a cold cache (the normal state right after connect) the label came back empty and the peripheral half was dropped, so split keyboards still showed only the central battery.

Now the label is read via ReadValue first (matching how the percentage is read), falling back to the cached Value, which also warms BlueZ's cache instead of depending on it already being warm. Verified live on a ZMK Corne — both halves now show.