Offer to reboot when toggling sudoless Docker; show only the relevant menu entry (#8098)

* Offer to reboot when toggling sudoless Docker; show only the relevant menu entry

Group membership only takes effect on a fresh session, and in practice a logout
or newgrp isn't enough — only a reboot reliably applies it. So the setup/remove
commands now flag the reboot and offer to do it now with a gum confirm (like the
GPU toggle), and the notices say "after a reboot" instead of pointing at logout
or newgrp. The existing-user migration passes OMARCHY_DEFER_REBOOT so it does not
prompt mid-update — omarchy-update-restart still handles the reboot once the whole
update finishes.

The Setup > Security menu also showed Sudoless Docker under both Setup and
Remove. Condition the Setup entry on the group being absent (Remove already
conditions on it being present), so only the applicable one appears.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gb7x6poap4hGCndPx5qt5T

* Ask omarchy-sudo-docker whether Docker needs sudo

Every place that chooses between talking to Docker directly and elevating was
testing group membership by hand, and the menu guards tested the wrong thing:
they read the running session's groups, which do not change until the reboot,
so after enabling sudoless Docker the menu still offered Setup — the one action
that could no longer do anything — while Remove stayed hidden.

Add omarchy-sudo-docker as the single answer, with the two questions that
actually differ in that window. By default it asks whether this session can
reach the socket, which is what decides if a command must elevate: lazydocker
and the Windows VM keep prompting until the reboot lands. With --configured it
asks whether the account is set up for sudoless Docker, which is what the menu
and the toggles need, so the menu switches to the action that can change state
as soon as the group is written.

Also correct a comment: nothing surfaces reboot-required in the bar; it is
omarchy-update-restart that reads it during a later update.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gb7x6poap4hGCndPx5qt5T

---------

Co-authored-by: David Heinemeier Hansson <david@hey.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

bin/omarchy-remove-security-sudoless-docker

@@ -5,7 +5,10 @@
 
 set -e
 
-if ! id -nG "$USER" 2>/dev/null | grep -qw docker; then
+# Ask about the configured groups, not this session's: right after enabling,
+# sudoless Docker is on for the account even though the running session still
+# needs a prompt, and this command is what turns it back off.
+if omarchy-sudo-docker --configured; then
   echo "Sudoless Docker is not enabled: $USER is not in the docker group."
   exit 0
 fi
@@ -13,13 +16,19 @@ fi
 echo "Removing $USER from the docker group..."
 sudo gpasswd -d "$USER" docker >/dev/null
 
-# Group membership is fixed at login, so the running session keeps its docker
-# access until it ends. Flag a reboot so omarchy-update-restart prompts for one
-# (and the bar shows it pending); a plain log out and back in works too.
+# Group membership is only re-read by a fresh session, and in practice logging
+# out or newgrp isn't enough — only a reboot reliably applies it. Record it so a
+# later `omarchy update` still prompts (omarchy-update-restart reads this), then
+# offer to do it now.
 omarchy-state set reboot-required
 
 echo ""
-echo "Sudoless Docker DISABLED. Reboot (or log out and back in) for the change to take effect."
-echo "Docker access now goes through a polkit/sudo prompt again: the Docker TUI"
-echo "(Super + Shift + D) and the Windows VM will ask when they need it, and the"
-echo "plain 'docker' CLI runs under sudo."
+echo "Sudoless Docker DISABLED. Docker access goes through a polkit/sudo prompt"
+echo "again: the Docker TUI (Super + Shift + D) and the Windows VM ask when they"
+echo "need it, and the plain 'docker' CLI runs under sudo. It takes effect after a reboot."
+echo ""
+# The migration reuses this command during 'omarchy update' and defers the
+# reboot to omarchy-update-restart, so it doesn't cut the update short.
+if [[ -z ${OMARCHY_DEFER_REBOOT:-} ]] && gum confirm "Reboot now to apply?"; then
+  omarchy-system-reboot
+fi