fix(catalog): accept git worktrees for gh-pages check

`need_ghpages` was testing `[[ -d "$GHPAGES_DIR/.git" ]]` — "is .git
a directory?". That's true for a regular clone but FALSE for a
`git worktree add` worktree, where `.git` is a pointer file (contains
`gitdir: …/main-repo/.git/worktrees/<name>`) rather than the
directory itself. `release.sh` creates the gh-pages worktree as
part of its flow; after release the worktree persists with a
`.git` file but `catalog.sh publish` would then refuse to run
because of the dir-only check.

Switched to `-e` (exists, either file or directory). Updated the
surrounding comment so the next poor soul doesn't delete the
worktree on the script's own (wrong) advice.

Caught when publishing the v2.2.0 template catalog — error told
the user to re-create a worktree that was already there and valid.

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

scripts/catalog.sh

@@ -45,7 +45,12 @@ need_builder() {
 }
 
 need_ghpages() {
-  [[ -d "$GHPAGES_DIR/.git" ]] || die "no gh-pages worktree at $GHPAGES_DIR
+  # `.git` is a directory in a regular clone but a pointer FILE in a
+  # `git worktree add` worktree — `-e` covers both. The earlier `-d`
+  # check falsely rejected worktrees, so the script's own error
+  # message told users to re-run `git worktree add` on a worktree
+  # that was already there and valid.
+  [[ -e "$GHPAGES_DIR/.git" ]] || die "no gh-pages worktree at $GHPAGES_DIR
   Run: git worktree add .gh-pages-worktree gh-pages"
 }