chore(tasks): record the passed real-cycle check for the resume hook

One RTC-woken suspend-then-hibernate cycle on AC showed btusb torn down and reloaded two seconds after resume, with bluetooth unblocked and powered afterwards. The dated entry under the sleep task carries the timestamps and what the cycle did not prove. The manual check is retired, and the entry-freeze test now re-checks bluetooth after each of its hibernate cycles, since that is the wake the hook exists for.

1 files changed, 20 insertions, 34 deletions

diff --git a/todo.org b/todo.org
index e735423..179054a 100644
--- a/todo.org
+++ b/todo.org
@@ -3220,6 +3220,18 @@ claims it does and needs correcting). The reload's one-second settle should
 make this hook's unblock land after =tlp resume=, and the re-check step is
 what shows it if the race goes the other way.
 
+*** 2026-10-05 Mon @ 23:08:31 -0600 Real-cycle check passed: the hook fires from /usr/lib
+One suspend-then-hibernate cycle on AC, RTC-woken after thirty seconds
+(suspend entry 23:07:01, exit 23:07:32, s2idle). The kernel logged btusb
+deregistered at 23:07:32 and registered again at 23:07:34, which is the hook's
+unload, settle and load, and rfkill logged "unblock set for type bluetooth"
+at 23:07:34, the hook's last command. No system-sleep line named the hook,
+and afterwards rfkill read "Soft blocked: no" with the controller "Powered:
+yes". The manual check under Manual testing is retired. Not proven by this
+cycle: the plain-suspend race with =tlp resume='s replay (it entered with
+bluetooth unblocked), and a true hibernate-class wake, which the entry-freeze
+test now checks after each of its cycles.
+
 *** TODO Hibernate entry freeze — confirm under observation, then mitigate :bug:velox:hibernate:
 Interim rule until this closes: do not hibernate unattended on battery. Shut
 down, or suspend on AC.
@@ -4170,9 +4182,17 @@ date; systemctl hibernate
 #+begin_src sh :results output
 journalctl -b -o short-iso | grep -E "systemd-sleep|hibernation (entry|exit)|Image allocation|Failed to put" | tail -6
 #+end_src
+- Check bluetooth came back. A hibernate re-probes the controller, and the
+  resume hook's btusb reload is what un-wedges it:
+#+begin_src sh :results output
+rfkill list bluetooth | grep Soft; bluetoothctl show | grep Powered; journalctl -b -o short-iso | grep -E "btusb|unblock set for type bluetooth|Failed to set mode" | tail -6
+#+end_src
 - Repeat until five cycles are logged.
 Expected: all five cycles power off within two minutes and resume into the
 same session, with "hibernation exit" and no "Image allocation … short" line.
+After each cycle bluetooth reads "Soft blocked: no" and "Powered: yes", the
+journal shows a btusb reload and "unblock set for type bluetooth", and no
+"Failed to set mode" line.
 A cycle where the screen stays black with the power LED on for more than five
 minutes is the entry freeze: hold power for 10 s, and write down the cycle
 number and whether the keyboard backlight was lit. A cycle that instead comes
@@ -5206,40 +5226,6 @@ Expected: =zfs holds= showed the =upgrade-guarded= tag on the snapshot step
 -Qkk= over the reconciled names reports no mismatch, including the package
 cut off mid-extraction.
 
-*** Bluetooth resume hook fires on a real sleep cycle
-What we're verifying: that =/usr/lib/systemd/system-sleep/zz-bluetooth-resume=
-runs at resume now that it lives in the one directory systemd-sleep scans. Its
-old home under =/etc/= was never scanned, so the proof is a btusb reload in the
-kernel log at the moment of resume, which about fifteen cycles never showed.
-Do it on AC. A twenty-second cycle only suspends, so the hibernate entry
-freeze does not come into it.
-- Confirm the starting state and note the time:
-#+begin_src sh :results output
-rfkill list bluetooth | grep Soft; bluetoothctl show | grep Powered; date +%H:%M:%S
-#+end_src
-- Start a suspend-then-hibernate cycle (the hook reloads btusb for that class
-  whether or not the hibernate stage was reached):
-#+begin_src sh :results output
-systemctl suspend-then-hibernate
-#+end_src
-- Wait about twenty seconds.
-- Wake it with a key press.
-- After the wake, read the kernel log. The hook itself logs nothing, and
-  systemd-sleep logs a hook only when it fails, so the system-sleep and
-  zz-bluetooth terms should match nothing on a pass:
-#+begin_src sh :results output
-journalctl -b -o short-iso --since "-5 min" | grep -E 'btusb|system-sleep|zz-bluetooth|Failed to set mode' | tail -12
-#+end_src
-- Re-check the radio state:
-#+begin_src sh :results output
-rfkill list bluetooth | grep Soft; bluetoothctl show | grep Powered
-#+end_src
-Expected: a "deregistering interface driver btusb" line and a fresh btusb
-registration, both stamped within seconds of the resume; no system-sleep line
-naming the hook; and the re-check still reads "Soft blocked: no" and
-"Powered: yes". If the log shows no btusb deregistration at all, the hook
-still is not running and the directory is not the cause.
-
 ** DOING [#B] Prepare for GitHub open-source release
 :PROPERTIES:
 :LAST_REVIEWED: 2026-08-17