feat: add ct init scaffolding and process workspaces

[bwl21]

Summary

• add ct init [directory] to scaffold a minimal config repository
• generate ct.config.ts, ct.envs.json, .gitignore, config/, and blueprints/
• collect the ChurchTools host, first environment, and optional Git initialization interactively
• support reproducible non-interactive initialization with --host, --env, --git/--no-git, and --yes
• refuse to overwrite existing scaffold files through a preflight check
• optionally verify and store an existing login token through a hidden prompt on macOS
• add an opt-in --template process quickstart for portable, instance-aware process workspaces

Process quickstart

The existing standard template remains the default. A reusable process inside an existing repository can be initialized explicitly:

ct init processes/example-process \
  --template process \
  --host https://example.church.tools \
  --env prod \
  --protected \
  --no-git \
  --yes

This creates:

<process>/
├── ct.config.ts
├── ct.envs.json
├── .gitignore
├── README.md
├── blueprint/
├── configs/
└── instances/
    └── example.church.tools/
        ├── ct-state.example.church.tools.json
        ├── backups/
        ├── reference/
        └── reports/

The root ct.config.ts is the normal entry point. ct.envs.json binds the environment to the normalized host, hostname-derived state path and protection status. The empty host-bound state is written immediately; the process template never creates a generic ct-state.json.

Portable definitions stay outside instances/. The generated README uses explicit ct plan -e <env> / ct apply -e <env> commands and reserves configs/ for exceptional -c entry points. Reports, backups and captured reference output remain under the matching instance and are ignored by default. No credentials or live ChurchTools IDs are generated.

Boundaries

• Process-specific groups, roles, rulesets, periods and approval criteria remain consumer-repository concerns.
• Requiring --env whenever ct.envs.json exists is a separate engine-wide safety change. This scaffold documents the requirement without changing the backward-compatible single-instance fallback from feat: environments — per-instance state + dev→prod promotion workflow #22.
• Username/password/TOTP token bootstrap remains the separate follow-up feat(auth): bootstrap login token from credentials and 2FA during init #138; related multi-environment auth ergonomics remain in ct auth status has no --env, so there is no way to ask "who am I on the other host?" #117.

Validation

• npm test — 823 passed, 5 skipped
• focused init/CLI tests — 18 passed
• npm run typecheck
• npm run lint
• npm run build
• documentation staleness check — all pages current
• Prettier check for every changed file
• git diff --check

The repository-wide Prettier command additionally sees unrelated local generated files under reference/ and reports/; those files were not modified or included in this PR.

Fixes #131