fix(archsetup): handle stow-created ~/.emacs.d when cloning dotemacs

The 2026-05-16 VM run surfaced `setting up emacs configuration files
(error code: 128)` with `fatal: not a git repository`. Root cause:
`dotfiles/common/.emacs.d/calendar-sync.local.el` lives in the stow
tree, so by the time the dotemacs clone step runs, `~/.emacs.d/`
already exists with a stowed symlink inside. The previous two-branch
check `[ -d "$emacs_dir" ]` then took the `git pull` path and failed
because the dir isn't a git checkout.

I replaced the check with three branches:

- `.git` exists → `git pull --recurse-submodules` (the existing
  upgrade path).
- Dir missing or empty → `git clone --recurse-submodules` (the fresh
  install path).
- Dir exists with content but no `.git` (the stow case, today's bug)
  → `git init` + `remote add origin` + `fetch --recurse-submodules` +
  `checkout -B main origin/main` + `submodule update --init
  --recursive`. This pulls the tree in on top of the stowed file
  without losing it.

The one-line `[ -d ]` → `[ -d .git ]` fix wouldn't have been enough on
its own: the clone branch would still fail because `git clone` refuses
a non-empty target.

`bash -n archsetup` is clean. The VM test run that surfaced the bug
exercised the old two-branch path. The new third branch wants a fresh
`make test` to verify before this lands on a real machine.

todo.org picks up two things this commit touches. The stale
gitrepos.sh reference under "Remove/template personal info from
scripts" comes out. A new sub-TODO under `[#B] Fix install errors`
expands the existing tidaler item: the same "AUR exit 0 logged as
error" pattern now hits six packages instead of one (tidaler,
mkinitcpio-firmware, speedtest-go-bin, rar, masterpdfeditor,
zsh-fast-syntax-highlighting-git). The recommendation points at
`aur_install` and the error-summary aggregator as trace targets.

0 files changed, 0 insertions, 0 deletions