--unattended: every question that has a default answers itself

51 yes/no prompts and ~20 free-text ones, of which about six actually need a human.
The line drawn is "a question with a default answers itself; a question with no
possible default still asks", so it stays attended without being a conversation.

Half of it already existed: ASSUME_YES=1 was implemented and honoured by confirm()
in both scripts, returning each question's OWN default — so a "do the thing you
asked for" question goes yes and a genuine extra goes no. --unattended sets it.

The new part is menu_answer(), for the eight numbered menus. It sets the variable
EMPTY rather than passing a default in, because every menu already consumes its
choice as `${CHOICE:-<n>}` — the default lives next to the options it selects
between, which is the right place, and a second copy in the helper could drift from
the one the prompt advertises. Verified all eight consume that way before touching
them. `read <<<''` rather than eval or `declare -g`, which is bash 4.2+ and rules
out the bash 3.2 macOS still ships.

officer-setup's ask_required takes its default too, except where there is none — the
owning account on a machine machine-setup never ran on, where a guess would install
as the wrong user.

STILL ASKS, deliberately: the username; the Tailscale control plane, login server
and auth key; the git identity; and an SSH public key when the account has none.
That last one is a trap I nearly walked into — on a fresh VPS KEY_COUNT==0 forces
ADD_KEY=true with no confirm, and the menu's default is "[1] paste a public key",
which then prompts with no default at all. Auto-answering that menu would hang or
fail, so it is excluded by name. adduser also still asks for a password; that is
the tool, not us.

Two pre-existing bugs fixed on the way: machine-setup's sudo re-exec passed "$@"
after `shift` had emptied it, so --only and --reask stopped existing the moment it
escalated — same bug as officer-setup had. And UNATTENDED/ASSUME_YES are named in
all three sudo lists, because env_reset would otherwise drop the flag at
escalation, which is now the fourth variable lost that way.

Verified: bash -n on five files, --help on all three, and menu_answer + confirm
under the flag showing a menu resolving to its default and a no-default confirm
correctly answering no.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

scripts/setup/machine-setup/lib/base.sh

@@ -285,6 +285,37 @@ page() {
 # deliberate keystroke would train people to hold the y key down.
 #
 # ASSUME_YES=1 answers all of them, for an unattended run.
+
+# A numbered menu's answer, or its own default when running unattended.
+#
+#   menu_answer DNS_CHOICE "  Which one? (1-5) [1]: "
+#
+# ── Why empty, rather than a default passed in ──
+#
+# Every menu in this script reads its choice and then consumes it as
+# `${CHOICE:-<n>}`, so the default already lives at the point of use — which is the
+# right place, next to the options it selects between. Setting the variable EMPTY is
+# therefore exactly what pressing Enter does, and it cannot drift from the default
+# the prompt advertises the way a second copy passed in here would.
+#
+# `read <<<''` rather than `eval` or `declare -g`: no eval, and `declare -g` is bash
+# 4.2+, which rules out the bash 3.2 that macOS still ships.
+#
+# The prompt is still printed, with the reason, because a transcript that silently
+# skips a question reads as a question that was never asked.
+menu_answer() {
+  local var="$1" prompt="$2"
+  if [[ "${UNATTENDED:-}" == "1" ]]; then
+    printf '%s%s\n' "$prompt" "— unattended, taking the default"
+    read -r "$var" <<<''
+    return 0
+  fi
+  read -rp "$prompt" "$var" || {
+    echo ""
+    fail "No answer."
+  }
+}
+
 confirm() {
   local message="${1:-Proceed?}"
   # Second argument flips the default. Most questions here are "do the thing you