feat(523): forge-connection tokens are stored sealed under SECRET_KEY, like the backup S3 secret

The column becomes token_sealed (migration 0122 seals existing rows with a
frozen copy of the v1 key), every reader opens it through connection_token,
a row this instance cannot open is skipped with a warning, and Settings asks
for that token again.

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

docs/backups.md

@@ -26,7 +26,9 @@ differently. It does **not** hold:
 - **Search indexes.** They are rebuilt from the records when Scribe starts.
 - **Sharing:** groups, project shares and note shares.
 - **Credentials:** API keys and forge connections. After a restore, issue new
-  API keys and add forge connections again.
+  API keys and add forge connections again. (Forge tokens are also sealed under
+  `SECRET_KEY` in the database itself, so a copy of the database doesn't carry
+  them in readable form either.)
 - **Logs and notifications.**
 - **The backup destination's own S3 secret.**
 

docs/configuration.md

@@ -9,7 +9,7 @@ Configuration is via environment variables. The `docker-compose.yml` file sets d
 | Variable | Default | Description |
 |----------|---------|-------------|
 | `DATABASE_URL` | `postgresql+asyncpg://fabled:fabled@db/scribe` | PostgreSQL async connection string |
-| `SECRET_KEY` | `dev-secret-change-me` | Session signing key — **change this in production** |
+| `SECRET_KEY` | `dev-secret-change-me` | Session signing key, and the key stored credentials are sealed under — **change this in production, then keep it** |
 | `SECRET_KEY_FILE` | — | Path to a Docker secret file containing the key (alternative to `SECRET_KEY`) |
 | `LOG_LEVEL` | `INFO` | Logging verbosity (`DEBUG`, `INFO`, `WARNING`, `ERROR`) |
 | `SECURE_COOKIES` | `false` | Set `true` when running behind TLS |
@@ -127,6 +127,7 @@ If using `TRUST_PROXY_HEADERS=true`, ensure your proxy strips any client-supplie
   python3 -c "import secrets; print(secrets.token_hex(32))"
   ```
   Or use Docker Secrets via `SECRET_KEY_FILE`.
+- **Keep `SECRET_KEY` once it is set.** Scribe seals the credentials it stores under a key derived from it: forge-connection tokens and the backup destination's S3 secret. A copy of the database alone can't read them. If the key changes (for example, a restore onto an instance with a different key), those credentials can no longer be opened. Settings marks each one and asks for it again, and nothing else breaks.
 - **`SECURE_COOKIES=true`** — must be set when running behind TLS.
 - **`BASE_URL`** — set to your public URL; required for OIDC redirects and email links.
 - **Registration** — auto-closes after the first user (admin). Re-enable from Settings → Users or send invite links.