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/BACKLOG.md

@@ -45,22 +45,6 @@ Reproduce from the launcher and a terminal, capture its stderr/journal, and
 fix the packaging/session/runtime cause. Pass = the default terminal opens in
 the installed graphical session and the SUPER+Return path works.
 
-### 96. Live ISO/install: battery charge-threshold menu is absent
-
-On this Acer the charge-threshold menu could not be found. Audit the hardware
-capability gate, live-ISO `power.laptop = false` policy/permissions, and menu
-discoverability. Unsupported hardware must get a clear explanation instead of
-looking like a missing feature; supported hardware must expose the control.
-Pass = the System/Power route communicates the correct state and never silently
-disappears, including in the live session.
-
-### 97. Live ISO/install: Bluetooth menu reports `Connection to BlueZ failed`
-
-Verify that BlueZ is enabled/running and that the live and installed user
-sessions can reach it before launching the picker. Pass = the Bluetooth menu
-opens normally on supported hardware; when the adapter/service is genuinely
-unavailable it shows a useful Nomarchy message rather than the raw failure.
-
 ### 98. Boreal: button text renders black and is difficult to read
 
 Audit GTK button foreground/background contrast under Boreal, including the

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

agent/JOURNAL.md

@@ -19,6 +19,24 @@ Template:
 
 ---
 
+## 2026-07-13 — #96+#97 menu gates explain instead of vanish/raw-fail (this commit)
+- **Task:** BACKLOG #96 (battery-limit row silently absent on threshold-less
+  firmware) and #97 (raw "Connection to BlueZ failed").
+- **Did:** rofi.nix — Battery limit row now gates on `has_system_battery`
+  (like Power profile); the leaf explains a missing
+  `charge_control_end_threshold` as a firmware capability. Bluetooth leaf
+  checks `bluetooth.service` before exec'ing blueman and explains the
+  service-down vs no-adapter (`/sys/class/bluetooth` empty) cases with
+  rfkill/firmware hints.
+- **Verified:** V1 — built nomarchy-menu, bash -n green, both new paths
+  present in the generated script; V0 flake check green. VM can't fake a
+  threshold-less battery or a BT adapter, so the behavioral checks are
+  queued: #96 → HARDWARE-QUEUE (Acer + T14s row check); #97 → the no-adapter
+  message is exercisable in the next QEMU run (planned with #94's
+  test-install pass; VMs have no BT adapter).
+- **Pending:** #97 V2 click-check in the next VM run; #96 V3 on the Acer.
+- **Next suggestion:** #94 test-install run (chromium launch + BT click).
+
 ## 2026-07-13 — #107 direct System/Tools menu keybinds (this commit)
 - **Task:** BACKLOG #107 — conflict-free direct bindings via keybinds.nix.
 - **Did:** `SUPER+CTRL+I` → `nomarchy-menu system` (Super+I settings muscle

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