real aliases for the owner, and eza to go with them

The owner's `aliases` block was one line — `alias sz`. Members got a full set from
shell-skel/zshrc and the owner got that. Replaced with the eza ls family, the
oh-my-zsh standards, and n/vim/sz/ld/httpserver.

eza added to all four core package lists. It is in the noble archive at 0.18.2-1,
so this is a package rather than a binary fetch, and Core utils is section 5 — well
before Shell at 26, so `command -v eza` is already true when the block is written.

The eza aliases are GUARDED behind `command -v eza` and the rest are not, and the
asymmetry is deliberate: these replace `ls`. Unguarded, a machine where eza failed
to install has no working `ls` in any new shell, which reads as a broken machine
rather than a missing package. `alias ld=lazydocker` without lazydocker is one
command-not-found when you type it — that can degrade honestly. Same principle
shell-skel/zshrc already holds to.

python3, not python, for httpserver: Ubuntu ships no `python` binary at all, so as
given it would have been a command-not-found on every machine this targets.

Checked the editor block first — it only exports EDITOR/VISUAL/SUDO_EDITOR, so
n and vim do not collide with anything already appended.

KNOWN: append_once returns 1 when its marker is already present, so a machine that
has already run this keeps the old one-line block and gets none of the above. That
is the function working as designed — it exists so a second run does not duplicate
its work, and it cannot tell a stale block from one the owner edited. Fix by hand:
delete the `# >>> machine-setup: aliases >>>` block from ~/.zshrc and re-run
`machine-setup.sh --only Shell`.

Verified: bash -n, zsh -n on the block, the eza guard leaving ls unset when eza is
absent, and vim resolving through n to nvim.

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

scripts/setup/machine-setup/machine-setup.sh

@@ -2309,8 +2309,41 @@ EOF
       ok "~/.local/bin and ~/.opencode/bin added to PATH"
     fi
 
+    # The eza aliases are GUARDED and the rest are not, for one reason: these
+    # replace `ls`. An unguarded `alias ls='eza --icons'` on a machine where eza
+    # failed to install leaves the owner with no working `ls` at all, in every new
+    # shell, which reads as a broken machine rather than a missing package. The
+    # others degrade honestly — `alias ld=lazydocker` without lazydocker is one
+    # command-not-found when you type it, not a core utility gone.
+    #
+    # Same principle shell-skel/zshrc already holds to: every optional tool is used
+    # only if present, so one file works on a minimal VPS and a full workstation.
     if append_once "$ZSHRC" aliases <<'EOF'
+if command -v eza >/dev/null 2>&1; then
+  alias ls='eza --icons'
+  alias la='eza --icons -la'
+  alias ll='eza --icons -l'
+  alias lll='eza --icons -lA'
+  alias lh='eza --icons -lhA'
+  alias ltr='eza --icons -ltr'
+  alias l='eza --icons -la'
+fi
+
+alias grep='grep --color=auto'
+alias less='less -R'
+alias diff='diff --color=auto'
+alias cp='cp -iv'
+alias mv='mv -iv'
+alias rm='rm -i'
+alias mkdir='mkdir -p'
+alias which='which -a'
+alias history='fc -l 1'
+
+alias n="nvim"
+alias vim="n"
 alias sz="source ~/.zshrc"
+alias ld="lazydocker"
+alias httpserver="python3 -m http.server 8888"
 EOF
     then
       ok "shell aliases added"