fix(security): pre-launch security hardening audit & remediation (#320)

- Webhook HMAC: capture raw request bytes via express.json verify callback
  instead of re-serializing with JSON.stringify
- AES-256-GCM: use NIST-recommended 12-byte IV (backward compatible with
  existing 16-byte IVs)
- Node proxy tokens: add 1-year default expiry (previously no expiry)
- Host console env filtering: pattern-based approach blocking SECRET,
  PASSWORD, TOKEN, KEY, CREDENTIAL keywords (previously only 4 explicit keys)
- CORS: deny cross-origin requests when FRONTEND_URL is unset in production
  (previously fell back to allowing all origins)

docs/features/host-console.mdx

@@ -57,6 +57,7 @@ The host console has a stricter authentication requirement than other features:
 - Requires a valid **browser session** (httpOnly cookie). Node-proxy tokens used for multi-node communication are explicitly blocked.
 - Each session is issued a short-lived **console token** (60-second TTL) before the WebSocket is established.
 - Access is restricted to the **Admiral** license tier, ensuring only teams with appropriate licensing can use interactive shell access.
+- Sensitive environment variables (names containing SECRET, PASSWORD, TOKEN, KEY, or CREDENTIAL, plus `DATABASE_URL`) are automatically stripped from the console environment so they cannot be read via `env` or `printenv`.
 - Because the console gives full shell access to the host, you should secure your Sencho instance with HTTPS and a strong password if it is exposed to a network.
 
 <Warning>

docs/features/multi-node.mdx

@@ -81,9 +81,10 @@ Click the **pencil icon** on any remote node row to edit its name, URL, or token
 
 ### Token security
 
-Node tokens are long-lived JWTs that grant full control over the remote Sencho instance. Treat them like passwords:
+Node tokens are JWTs with a default **1-year expiry** that grant full control over the remote Sencho instance. Treat them like passwords:
 
 - **Rotate immediately** if a token is compromised: Settings → Nodes → Generate Token on the remote instance. The old token is invalidated instantly.
+- Tokens **expire after 1 year** by default. Generate a new token on the remote instance to renew access.
 - Tokens are **encrypted at rest** using AES-256-GCM in Sencho's SQLite database. Even if the database file is extracted, the tokens cannot be read without the instance's encryption key.
 - Tokens are scoped to `node_proxy` — they cannot access the host console or container exec terminals. Interactive shell access always requires a real browser session on that specific instance.
 

docs/features/webhooks.mdx

@@ -127,5 +127,6 @@ Each webhook tracks its last 100 executions. Click **Recent executions** on any
 - Webhook secrets are 64-character hex strings generated with `crypto.randomBytes(32)`
 - Signature validation uses `crypto.timingSafeEqual` to prevent timing attacks
 - Secrets are shown only once at creation - API responses return masked values
+- Signature verification uses the raw request bytes, not re-serialized JSON, to prevent serialization-induced mismatches
 - Webhook trigger endpoints are public (no session cookie required) but protected by HMAC signature validation
 - Each webhook targets a single stack - there is no way to execute arbitrary commands