port the shell section, and make one starship config serve both audiences

os-user-shell.ts:33 calls scripts/setup/starship.toml "the prompt config the
owner's own install uses — one file, both audiences". It was not: the original
machine script wrote a DIFFERENT config inline, so the owner got a prompt that
only disabled language modules while every member got the repo file with its
custom format. Two prompts, one comment claiming otherwise.

This deploys the same file the platform does, which makes the comment true.
Verified with cmp against a fresh account: byte-identical to what a member gets.

Nothing overwrites any more:

  .config/starship.toml and .tmux.conf go through install_config, so they are
  written when absent, skipped when identical, and KEPT when they differ — with
  the cp printed, so taking ours stays the reader's decision. On this host that
  is what happens: the existing config differs and is left alone.

  The starship line in .zshrc is marker-wrapped by append_once. Verified over
  three consecutive runs: one block, not three. The original appended it
  unguarded every time.

The login shell is now its own question. Having zsh on the machine and being
handed it at every login are different decisions, and `chsh` made the second one
silently. It also adds the shell to /etc/shells first, which chsh requires.

.tmux.conf lives here now, with the rest of the dotfiles, rather than in user
creation where the original put it only because that is where $USER_HOME first
exists.

One bug found by running it: install_config returns 2 for "kept yours", which is
an outcome rather than a failure — but still non-zero, so calling it as a plain
command under `set -e` ended the run before `case $?` could read it. Captured with
&& / || at both call sites, and the contract is documented where the function is
defined so the next caller does not repeat it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

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

@@ -62,3 +62,40 @@ ask_required() {
   done
   printf -v "$__var" '%s' "$answer"
 }
+
+# -----------------------------------------------------------------------------
+# Shell
+# -----------------------------------------------------------------------------
+#
+# ── One starship config, not two ──
+#
+# The platform deploys scripts/setup/starship.toml into every member's home
+# (os-user-shell.ts), and the comment there calls it "the prompt config the
+# owner's own install uses — one file, both audiences". That was not true: the
+# original machine script wrote a DIFFERENT config inline, so the owner got one
+# prompt and every member got another. This deploys the same file the platform
+# does, which makes the comment true rather than aspirational.
+#
+# It lives one directory up because it is shared with the platform, not owned by
+# this script.
+STARSHIP_SRC="${STARSHIP_SRC:-$SCRIPT_DIR/../starship.toml}"
+
+user_login_shell() { getent passwd "$USERNAME" | cut -d: -f7; }
+
+oh_my_zsh_installed() { [[ -d "${USER_HOME}/.oh-my-zsh" ]]; }
+
+install_oh_my_zsh() {
+  # The installer refuses to run unattended over an existing install, so this is
+  # only ever called when there is none.
+  sudo -H -u "$USERNAME" sh -c \
+    "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" "" --unattended >/dev/null 2>&1
+}
+
+# `chsh` is what actually changes the login shell. Asked separately from
+# installing zsh, because having a shell available and being handed it at every
+# login are different decisions.
+set_login_shell() {
+  local shell="$1"
+  grep -qxF "$shell" /etc/shells || echo "$shell" >>/etc/shells
+  chsh -s "$shell" "$USERNAME"
+}