fix(new-setup): avoid double-bootstrap and corepack EACCES on system Node

Two fixes to the fresh-install path:

1. setup.sh: when `corepack enable` runs as a non-root user against a
   system-wide Node install (apt-installed to /usr/bin), it fails EACCES
   trying to symlink /usr/bin/pnpm, leaving pnpm off PATH. Retry with
   sudo when pnpm is still missing — gated to Linux/WSL so macOS
   Homebrew prefixes aren't polluted with root-owned shims.

2. SKILL.md step 1: if the probe reports STATUS: unavailable (Node not
   installed), install Node BEFORE invoking `bash setup.sh`. The old
   flow ran setup.sh first as a diagnostic, which always failed fast,
   installed Node, then re-ran — two bootstraps for no reason.

Combined: fresh Linux box now goes Node install -> single setup.sh run.

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

setup.sh

@@ -72,10 +72,21 @@ install_deps() {
 
   cd "$PROJECT_ROOT"
 
-  # Enable corepack for pnpm
+  # Enable corepack so `pnpm` shim lands on PATH.
   log "Enabling corepack"
   corepack enable >> "$LOG_FILE" 2>&1 || true
 
+  # On Linux/WSL with system-wide Node (e.g. apt-installed to /usr/bin),
+  # corepack needs root to symlink /usr/bin/pnpm. Retry with sudo when pnpm
+  # isn't on PATH. macOS Homebrew installs land in a user-writable prefix,
+  # and a sudo retry there would create root-owned shims inside /opt/homebrew
+  # that later break brew — so the retry is Linux-only.
+  if ! command -v pnpm >/dev/null 2>&1 && [ "$PLATFORM" = "linux" ] \
+      && command -v sudo >/dev/null 2>&1; then
+    log "pnpm not on PATH after corepack enable — retrying with sudo"
+    sudo corepack enable >> "$LOG_FILE" 2>&1 || true
+  fi
+
   log "Running pnpm install --frozen-lockfile"
   if pnpm install --frozen-lockfile >> "$LOG_FILE" 2>&1; then
     DEPS_OK="true"