move host setup into scripts/setup/

scripts/ was holding two unrelated kinds of thing: install-this-machine, and run-this-occasionally. The
eight installers now live in scripts/setup/; what stays at the top level is the build steps (gen-index,
prebuild, build/) and the two maintenance scripts (reindex-music, rebuild-soulseek-tree).

The move is not just a rename. Three of these derive the repo root from their own location:

  setup.sh:51            PROJECT_DIR="$(dirname "$SCRIPT_DIR")"
  setup_mac_light.sh:51  same
  cleanup-desktop.sh:134 ENV_FILE="$(dirname "$0")/../.env"

Left alone, all three would now resolve to scripts/ — and nothing downstream complains. PROJECT_DIR is
where .env is written, where `bun install`, `gen:index` and `db:push` run, and what pm2 is pointed at, so
a fresh install would have quietly provisioned scripts/ and reported success. cleanup-desktop.sh fails
the other way: it would find no .env, print "No .env — skipping", and leave the real VNC_PASSWORD in the
real file. All three are now `../..` with a comment saying why the level matters.

provision-user-dirs.ts imports data-path.ts relatively; that one tsgo caught.

Also disambiguated `setup.sh` where it had become two files. app-store/templates/<name>/setup.sh is a
per-sidecar installer with its own contract, and preflight.ts + docs/sidecar-app-store.md discussed both
in the same paragraph. The host one is now spelled with its full path at those sites.

Verified: bash -n on all six shell scripts, tsgo clean, os-user tests pass, both derivations resolve to
the repo root, starship.toml still resolves from os-user-shell.ts, and provision-user-dirs.ts runs under
DRY_RUN.

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

src/servers/app-store/preflight.ts

@@ -9,9 +9,10 @@ import type { CatalogueEntry } from './catalogue';
 //
 // ── What this deliberately does NOT do ──
 //
-// It does not install anything. Today nothing in `scripts/` installs Docker either — `setup.sh` runs
-// `setup-dockers.sh`, which invokes `docker compose` without ever checking it exists, so a fresh host
-// without Docker fails partway through setup with a bare "command not found". That is a real gap, and
+// It does not install anything. Today nothing in `scripts/` installs Docker either — the host installer
+// `scripts/setup/setup.sh` runs `scripts/setup/setup-dockers.sh`, which invokes `docker compose` without
+// ever checking it exists, so a fresh host without Docker fails partway through setup with a bare
+// "command not found". That is a real gap, and
 // the intended fix is a per-sidecar `setup.sh` that ensures its own dependencies — which is also the
 // shape a sidecar needs once it lives in its own repository and ships independently.
 //

src/servers/data-path.ts

@@ -50,7 +50,7 @@ export const getOwnerHomeDir = (email: string): string => process.env.HOME_DIR ?
 // non-owner's sessions would run.
 //
 // Single-sourced here rather than in the script that used to own the list, because there are now two
-// callers — `scripts/provision-user-dirs.ts` and the owner's create-account handler — and a skeleton
+// callers — `scripts/setup/provision-user-dirs.ts` and the owner's create-account handler — and a skeleton
 // that differs depending on how the account was made is a bug nobody would think to look for.
 export const USER_DIRS = ['home', 'attachments', 'cache', 'dashboards', 'email_accounts', 'logs', 'sidecar'] as const;
 

src/servers/os-user-claude.ts

@@ -8,7 +8,7 @@ import { osUserHome, runAs } from './os-user';
 // A single `/usr/local/bin/claude` would be less disk and one version to reason about, and the argument for
 // it is real: the private part of Claude is the credential in `~/.claude`, not the executable. It is still
 // the wrong shape here. `claude` updates itself — that is why the owner's own install goes through
-// Anthropic's installer rather than npm (`scripts/setup.sh:853`) — and a root-owned binary is one a member
+// Anthropic's installer rather than npm (`scripts/setup/setup.sh:861`) — and a root-owned binary is one a member
 // cannot update, which turns "my agent is a version behind" into a request to the owner. Per-member also
 // means the account's agent keeps working exactly as the tool ships, with no platform-shaped exception to
 // explain. Same command the owner ran, run as them, in their home.
@@ -29,7 +29,7 @@ import { osUserHome, runAs } from './os-user';
 // report whether the credential has appeared, so the UI can render the one-line instruction instead of an
 // agent that fails for reasons nobody can see.
 
-/** Anthropic's own installer — the same one `scripts/setup.sh` uses for the owner, chosen for auto-update. */
+/** Anthropic's own installer — the same one `scripts/setup/setup.sh` uses for the owner, chosen for auto-update. */
 const CLAUDE_INSTALL_URL = 'https://claude.ai/install.sh';
 
 /**

src/servers/os-user-shell.ts

@@ -14,7 +14,7 @@ import { osUserHome } from './os-user';
 //
 // ── What it is ──
 //
-// `shell-skel/zshrc` → `~/.zshrc`, and the platform's own `scripts/starship.toml` → `~/.config/starship.toml`
+// `shell-skel/zshrc` → `~/.zshrc`, and the platform's own `scripts/setup/starship.toml` → `~/.config/starship.toml`
 // so a member's prompt is the same one the owner's install deploys. That file is the single source for both:
 // setup.sh copies it for the owner and this copies it for everybody else, so the two cannot drift.
 //
@@ -31,7 +31,7 @@ import { osUserHome } from './os-user';
 /** Where the templates live, relative to this file. */
 const SKEL_DIR = join(import.meta.dir, 'shell-skel');
 /** The prompt config the owner's own install uses — one file, both audiences. */
-const STARSHIP_SRC = join(import.meta.dir, '../../scripts/starship.toml');
+const STARSHIP_SRC = join(import.meta.dir, '../../scripts/setup/starship.toml');
 
 type SudoResult = { ok: boolean; out: string };