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>

modules/home/rofi.nix

@@ -483,6 +483,18 @@ ${themeRows}
         # it's invoked directly with nomarchy.system.bluetooth.enable=false.
         command -v blueman-manager >/dev/null 2>&1 \
           || { notify-send "Bluetooth" "Not available (nomarchy.system.bluetooth off?)."; exit 0; }
+        # blueman shows a raw "Connection to BlueZ failed" when bluetoothd
+        # isn't up (BACKLOG #97) — it never runs on machines whose adapter
+        # is absent, unpowered, or rfkill-blocked (bluetooth.service is
+        # udev-triggered on /sys/class/bluetooth). Explain instead.
+        if ! systemctl is-active --quiet bluetooth.service; then
+          if ls /sys/class/bluetooth/hci* >/dev/null 2>&1; then
+            notify-send "Bluetooth" "The Bluetooth service is not running. Try: systemctl start bluetooth — if it fails, check 'rfkill list' for a blocked adapter."
+          else
+            notify-send "Bluetooth" "No Bluetooth adapter detected on this machine (nothing in /sys/class/bluetooth). If it has one, it may be disabled by a hardware switch or missing firmware — check 'rfkill list' and 'journalctl -k -g bluetooth'."
+          fi
+          exit 0
+        fi
         exec blueman-manager ;;
 
       printers)
@@ -1148,9 +1160,11 @@ ${themeRows}
           if has_system_battery && command -v powerprofilesctl >/dev/null 2>&1; then
             row "Power profile" preferences-system-power
           fi
-          # Self-gated on the charge-threshold sysfs node (laptops that
-          # expose it), like Power profile above.
-          has_charge_threshold && row "Battery limit" battery-080
+          # Gated on a battery (like Power profile), NOT on the
+          # charge-threshold sysfs node: firmware without the control must
+          # get the leaf's explanation, not a silently missing row that
+          # reads as a broken feature (BACKLOG #96, Acer M5-481T).
+          has_system_battery && row "Battery limit" battery-080
           back
         } | rofi_menu -show-icons -markup-rows -p System) || exit 0
         case "$choice" in
@@ -1183,7 +1197,9 @@ ${themeRows}
         # Persist + live sysfs apply (same as powermgmt). Boot/AC re-apply
         # stays with the oneshot in power.nix.
         has_charge_threshold \
-          || { notify-send "Battery limit" "No charge-threshold control on this machine."; exit 0; }
+          || { notify-send "Battery limit" \
+                 "This machine's firmware does not expose a charge-stop control (no charge_control_end_threshold in /sys), so a charge limit cannot be set here. The battery still works normally — this is a hardware capability, not a Nomarchy problem."
+               exit 0; }
         cur=$(nomarchy-theme-sync get settings.power.batteryChargeLimit 2>/dev/null)
         sel=$( {
           row "80% (recommended)"    battery-080