feat(setup): enter the domain once via setup.env; stop drifting the secrets (#16)

The first-run flow generated ./config/*.js with example.com/dc=example,dc=com
defaults and then exit 0'd, telling the operator to hand-edit. The domain/base
DN was repeated across ~9 fields in each secrets file; on the deploy host only
the stack block was updated (to dc=718it,dc=biz) while ldap.* DNs stayed at
dc=example,dc=com, so slapd's root DN didn't match the app's bindDN and
bootstrap failed with 401 Invalid Credentials.

Enter the domain once: a new setup.env (gitignored; setup.env.example is the
committed template) holds the essential, non-repeating first-run info — the
domain as an LDAP base DN (CFG_BASE_DN). setup.sh reads it ONLY on first run
(when ./config/*.js don't exist), derives hostnames (sso.<domain> /
proxy.<domain>) and all LDAP DNs from it, generates both secrets files with
the real domain filled in everywhere + random secrets, and proceeds to build
in the same run (no edit-and-re-run step). After first run the secrets files
are operator-owned and setup.env is ignored — the apps and secrets files are
unchanged.

- setup.sh ensure_config: source setup.env -> bind CFG_* to empty (set -u
  safe) -> unchanged .env/proxy.env legacy migration -> derive from base DN
  (no example.com defaults; die with a helpful msg if CFG_BASE_DN blank) ->
  generate + proceed. Header comments updated.
- setup.env.example: committed template; secrets stay out (generated into
  ./config/*.js).
- .gitignore: ignore setup.env (per-deployment).
- README.md + docs/quickstart.md: Quickstart now cp setup.env.example ->
  set CFG_BASE_DN -> ./setup.sh; domain-asked-once note in "Before you begin".
- Bump sso-manager-node gitlink to 11fb2c0 (docs PR #37: base-DN-is-the-one-
  domain-value note in sso-manager README/DEPLOYMENT/secrets.js.example).

Co-authored-by: Claude <noreply@anthropic.com>

docs/quickstart.md

@@ -32,32 +32,36 @@ step. If you forgot it:
 git submodule update --init --recursive
 ```
 
-## 2. Configure `./config/`
+## 2. Configure `setup.env` (enter your domain once)
 
 ```bash
-./setup.sh        # generates ./config/ with random secrets, then exits
+cp setup.env.example setup.env
+$EDITOR setup.env      # set CFG_BASE_DN to your domain, as a base DN
 ```
 
-The first `./setup.sh` generates `./config/sso-secrets.js` +
-`./config/proxy-secrets.js` and **exits**, telling you to edit. Edit
-`./config/sso-secrets.js` and at minimum set:
+Your domain is entered **once**, as the LDAP base DN. The SSO/proxy hostnames
+default to `sso.<domain>` / `proxy.<domain>`, derived from it, so for most setups
+`CFG_BASE_DN` is the only value you set:
 
-| Key (in `sso-secrets.js`) | Example | Notes |
+| `setup.env` key | Example | Notes |
 |-----|---------|-------|
-| `stack.ldapBaseDn` | `dc=lab,dc=local` | your directory base |
-| `stack.ssoHost` | `sso.lab.local` | hostname the proxy serves the SSO UI at |
-| `stack.proxyHost` | `proxy.lab.local` | hostname the proxy serves its own UI at |
-| `bootstrap.adminUid` | `admin` | your first admin login |
-| `bootstrap.adminPass` | `...` | first admin password |
+| `CFG_BASE_DN` | `dc=lab,dc=local` | your directory base — **required** |
+| `CFG_SSO_HOST` | `sso.lab.local` | optional, defaults to `sso.<domain>` |
+| `CFG_PROXY_HOST` | `proxy.lab.local` | optional, defaults to `proxy.<domain>` |
+| `CFG_ADMIN_UID` | `admin` | optional, defaults to `admin` |
+| `CFG_ADMIN_EMAIL` | `admin@<proxyHost>` | optional |
 
-Random secrets (`ldap.bindPassword`, `oauth.jwtSecret`, `serviceAccountPass`)
-are generated for you — change them in the file if you like. Optional:
-`bootstrap.adminEmail`, `smtp.*`, `stack.ldapCertCn`. See `config.example/` for
-the full annotated shape, and each submodule's `secrets.js.example`.
+`setup.env` is used **only on the first run** to generate `./config/`; after
+that `./config/*.js` are operator-owned and `setup.env` is ignored. Secrets
+(LDAP admin password, JWT, admin password, service-account password) are
+**generated** into `./config/*.js` on first run — do **not** put them in
+`setup.env`. See `setup.env.example` for the full annotated shape, and
+`config.example/` + each submodule's `secrets.js.example` for the generated
+file shape.
 
 > **Migrating from an older `.env`-based deployment?** If `.env`/`proxy.env`
 > exist, `./setup.sh` migrates them into `./config/` preserving your existing
-> secrets — no need to reconfigure.
+> secrets — no need to write a `setup.env`.
 
 ## 3. Run
 
@@ -65,6 +69,9 @@ the full annotated shape, and each submodule's `secrets.js.example`.
 ./setup.sh
 ```
 
+The first run reads `setup.env`, generates `./config/sso-secrets.js` +
+`./config/proxy-secrets.js` with your domain filled in everywhere plus random
+secrets, then builds and starts the stack in the same run (no edit-and-re-run).
 What happens:
 
 1. Snapshots state to `./backups/<timestamp>/` before rebuilding (a no-op on the