fix(menu): explain unsupported battery-limit and BlueZ-down states

BACKLOG #96 + #97 (Acer live pass). Battery limit: the System row now
gates on battery presence (same rule as Power profile) instead of the
charge-threshold sysfs node, so firmware without the control gets the
leaf's explanation ("no charge_control_end_threshold — hardware
capability") rather than a silently missing row that reads as a broken
feature. Bluetooth: the leaf checks bluetooth.service before launching
blueman-manager and replaces the raw "Connection to BlueZ failed" with
a state-aware message (service stopped vs no adapter in
/sys/class/bluetooth, with rfkill/firmware hints).

Verified: V1 — nomarchy-menu builds, bash -n green, both paths in the
generated script; V0 flake check green. QEMU can fake neither a
threshold-less battery nor a BT adapter: #96 behavioral check queued in
HARDWARE-QUEUE (Acer + T14s); #97's no-adapter message will be
click-checked in the next VM run (V2 pending).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

agent/HARDWARE-QUEUE.md

@@ -11,6 +11,13 @@ the **T14s** (webcam case).
 
 ## Any machine (dev box is fine)
 
+- [ ] **#96 battery-limit row on threshold-less firmware (Acer M5-481T)** —
+      on the Acer (live or installed session with the commit carrying this
+      entry): open System (`SUPER+CTRL+I`). **Pass:** a "Battery limit" row
+      IS listed (battery present); picking it shows the notification
+      explaining the firmware exposes no charge-stop control (not a raw
+      error, and the row never silently disappears). On the T14s the row
+      must still open the working preset picker.
 - [ ] **#101 charge-limit service survives USB-C power-event bursts**
       (round 2) — round 1 FAILED on TuringMachine 2026-07-13 18:16: a
       *spaced* storm (each run finished before the next AC event) landed 5