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.**