Externalize auth secrets to .env and rename default config to triggershell.yml

sessionSecret was previously baked directly into the scaffolded config file;
`triggershell init` now generates a .env with TRIGGERSHELL_SESSION_SECRET
instead and references it via ${VAR} interpolation, keeping the actual
secret out of the (often committed) config file. `triggershell dev/start/
validate` load that .env automatically without overriding real env vars.

Also renames the default config filename from triggershell.config.yaml to
triggershell.yml throughout the CLI, app, docs, and examples.

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

README.md

@@ -25,12 +25,12 @@ API for automation.
 
 ```bash
 pip install triggershell         # or: pip install -e . from a checkout
-triggershell init                # scaffold triggershell.config.yaml in the current directory
+triggershell init                # scaffold triggershell.yml (+ .env for secrets) in the current directory
 triggershell users add admin     # create a login (skip if you set auth.enabled: false)
 triggershell dev                 # start in dev mode and open the browser
 ```
 
-Edit `triggershell.config.yaml` to add your own scripts (see [Configuration](#configuration) below),
+Edit `triggershell.yml` to add your own scripts (see [Configuration](#configuration) below),
 then run `triggershell start` for a production build.
 
 ## Requirements
@@ -41,8 +41,10 @@ then run `triggershell start` for a production build.
 
 ## Configuration
 
-TriggerShell is driven entirely by one YAML file (default: `./triggershell.config.yaml`, override
-with `-c/--config` or `TRIGGERSHELL_CONFIG_PATH`). Minimal example:
+TriggerShell is driven entirely by one YAML file (default: `./triggershell.yml`, override with
+`-c/--config` or `TRIGGERSHELL_CONFIG_PATH`). Secrets referenced via `${VAR}` (like
+`auth.sessionSecret`) are meant to live in a `.env` file next to the config, not in the config
+itself — `triggershell init` generates both. Minimal example:
 
 ```yaml
 server:
@@ -84,8 +86,9 @@ scripts:
         argName: --dry-run
 ```
 
-A full, richly-commented example lives at [`examples/triggershell.config.yaml`](examples/triggershell.config.yaml),
-and the complete field-by-field reference is in [`docs/CONFIG_REFERENCE.md`](docs/CONFIG_REFERENCE.md).
+A full, richly-commented example lives at [`examples/triggershell.yml`](examples/triggershell.yml)
+(with a matching [`.env.example`](examples/.env.example)), and the complete field-by-field
+reference is in [`docs/CONFIG_REFERENCE.md`](docs/CONFIG_REFERENCE.md).
 
 Each variable's `type` (`string` / `number` / `boolean` / `enum` / `multiselect`) picks a sensible
 default UI control; set `control` explicitly to override it (e.g. `slider` for a `number`, `radio`
@@ -96,7 +99,7 @@ the script — always as a discrete argv element or env var, never interpolated
 
 | Command | Description |
 |---|---|
-| `triggershell init [PATH]` | Scaffold a new config file (`--port`, `--auth/--no-auth`, `--force`) |
+| `triggershell init [PATH]` | Scaffold a new config file + `.env` (`--port`, `--auth/--no-auth`, `--force`) |
 | `triggershell validate [-c CONFIG]` | Validate a config file (fast Python pre-flight + full Node/Zod schema) |
 | `triggershell dev [-c CONFIG] [--port] [--host] [--no-browser]` | Run in development mode (hot reload) |
 | `triggershell start [-c CONFIG] [--port] [--host] [--no-browser] [--skip-build]` | Build (if stale) and run in production mode |
@@ -173,6 +176,9 @@ See [`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md) for how the pieces fit togeth
 - The server binds to `127.0.0.1` by default — set `server.host` explicitly to expose it further.
 - Route Handlers check auth themselves (`requireAuth()`); `proxy.ts` is only a fast, optimistic
   redirect layer, not the security boundary.
+- `auth.sessionSecret` should live in `.env`, not the config file — `triggershell init` sets this
+  up for you. Only `passwordHash`/`tokenHash` values (one-way hashes, not the secrets themselves)
+  belong in the config.
 
 ## License