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

Backport of the sudoless Docker follow-up (PR #8098, merged to quattro as
06a3dbca) onto the v4-0-1 release branch, on top of the #8056 and #8080
backports it follows.

Group membership only takes effect on a fresh session, and in practice a logout
or newgrp is not enough -- only a reboot reliably applies it. The setup and
remove commands now flag the reboot and offer to do it right away with a gum
confirm, the same shape as the GPU toggle, and their notices say "after a
reboot" instead of pointing at logout or newgrp. The existing-user migration
reuses the removal command inside omarchy update, so it passes
OMARCHY_DEFER_REBOOT to skip the prompt there and lets omarchy-update-restart
handle the reboot once the whole update has finished.

Setup > Security showed Sudoless Docker under both Setup and Remove, and the
guards tested the running session's groups, which do not change until the
reboot: 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 to both questions that differ in that
window -- by default whether this session can reach the socket, which is what
decides if a command must elevate, and with --configured whether the account is
set up for it, which is what the menu and the toggles need. It succeeds when
sudo is needed, so the Setup entry appears while sudoless Docker is off and
Remove once it is on. lazydocker and the Windows VM keep prompting until the
reboot lands.

Clean cherry-pick on top of the earlier backports: every file is byte-identical
to quattro except default/omarchy/omarchy-menu.jsonc, which merged into this
branch's menu and whose two Sudoless Docker lines match quattro exactly.
test/shell passes: 188 files, including the two this adds. test/cli passes, so
the new command's metadata is well-formed. Exercised the helper here: with no
socket it reports sudo is needed, and --configured answers from the account's
groups.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018DEMYa9UWtroz93DhMTtcV

test/shell.d/sudo-docker-test.sh

@@ -0,0 +1,67 @@
+#!/bin/bash
+#
+# omarchy-sudo-docker is the single answer to "does Docker need sudo", and it
+# answers two different questions on purpose. The default asks whether this
+# session can reach the socket, which is what decides if a command must elevate.
+# --configured asks whether the account is set up for sudoless Docker, which is
+# what the menu needs so it offers the toggle that can change state. Between
+# enabling sudoless Docker and the reboot that grants the group, those disagree.
+
+set -euo pipefail
+
+source "$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)/base-test.sh"
+
+TMPDIR=$(mktemp -d)
+trap 'rm -rf "$TMPDIR"' EXIT
+
+command="$ROOT/bin/omarchy-sudo-docker"
+
+# Stub id so the configured groups are controllable.
+mkdir -p "$TMPDIR/bin"
+cat >"$TMPDIR/bin/id" <<'STUB'
+#!/bin/bash
+printf '%s\n' "${STUB_GROUPS:-wheel input}"
+STUB
+chmod +x "$TMPDIR/bin/id"
+
+# A writable stand-in means the socket is reachable; an unwritable one means it
+# is not. Test the file mode rather than a live daemon.
+reachable_socket="$TMPDIR/reachable.sock"
+blocked_socket="$TMPDIR/blocked.sock"
+touch "$reachable_socket" "$blocked_socket"
+chmod 600 "$reachable_socket"
+chmod 400 "$blocked_socket"
+
+run() { # SOCKET GROUPS [--configured]
+  env PATH="$TMPDIR/bin:$PATH" OMARCHY_DOCKER_SOCKET="$1" STUB_GROUPS="$2" USER=tester \
+    bash "$command" ${3:+"$3"}
+}
+
+# Default mode follows the socket, not the group list.
+run "$blocked_socket" "wheel input" || fail "an unreachable socket means Docker needs sudo"
+run "$reachable_socket" "wheel input" && fail "a reachable socket means Docker does not need sudo"
+pass "default mode answers from the socket this session can reach"
+
+# A socket that isn't there at all still needs elevation (starting it is root work).
+run "$TMPDIR/absent.sock" "wheel input docker" || fail "a missing socket means Docker needs sudo"
+pass "a missing socket counts as needing sudo"
+
+# --configured follows the account's groups, not the socket.
+run "$blocked_socket" "wheel input docker" --configured && fail "a configured docker group means no sudo is needed"
+run "$reachable_socket" "wheel input" --configured || fail "no docker group means sudo is needed"
+pass "--configured answers from the account's groups"
+
+# The window this split exists for: sudoless Docker has just been enabled, so the
+# account carries the group while the running session still cannot use it. The
+# menu must offer Remove (--configured says no sudo) while lazydocker and the
+# Windows VM must still prompt (default says sudo).
+run "$blocked_socket" "wheel input docker" || fail "the session still needs sudo before the reboot"
+run "$blocked_socket" "wheel input docker" --configured && fail "the account is already configured for sudoless Docker"
+pass "the two modes disagree between enabling sudoless Docker and the reboot"
+
+# An unknown argument is a usage error, not a silent answer either way.
+run "$reachable_socket" "wheel input" --bogus 2>/dev/null && fail "an unknown flag exits non-zero"
+status=0
+run "$reachable_socket" "wheel input" --bogus >/dev/null 2>&1 || status=$?
+(( status == 2 )) || fail "an unknown flag exits 2, not the boolean 1"
+pass "an unknown flag is a usage error"