fix(security): Encrypt Slack and Telegram bot tokens at rest (Invariant #13)

[vybe]

Problem

Bot tokens for external messaging integrations are stored as plaintext in SQLite, violating Architectural Invariant #13 (Credentials: never stored in DB; transient secrets in Redis; encrypted exports use AES-256-GCM).

Confirmed plaintext storage

• slack_link_connections.slack_bot_token — TEXT NOT NULL (src/backend/db/schema.py:539, db/migrations.py:537)
• slack_workspaces.bot_token — TEXT NOT NULL (db/migrations.py:863)
• telegram_chat_links bot tokens — plaintext (see adapters/telegram_adapter.py and db.get_telegram_bot_token)

Writes happen in db/slack.py:create_slack_connection and matching Telegram paths without any encryption layer.

Architecture doc is inaccurate

docs/memory/architecture.md claims slack_workspaces stores "encrypted bot tokens (encrypted at application layer)" — this is false and should be corrected as part of this fix.

Impact

Slack/Telegram bot tokens grant full workspace messaging access. A DB leak (backup exfil, SQLite file access, read-only replica exposure) reveals live credentials that can impersonate Trinity agents in user workspaces. Trinity already has an encryption primitive: services/credential_encryption.py (AES-256-GCM, used for .credentials.enc).

Scope

• Encrypt bot tokens at write, decrypt at read for:
  • slack_link_connections.slack_bot_token
  • slack_workspaces.bot_token
  • Telegram bot token storage (telegram_chat_links or equivalent)
• Reuse services/credential_encryption.py (AES-256-GCM) or add an equivalent helper keyed off SECRET_KEY / dedicated env var.
• Migration strategy for existing rows:
  • Option 1: one-shot migration that encrypts in place at startup (needs versioned migration in db/migrations.py).
  • Option 2: lazy migration — encrypt on next write, tolerate both formats on read. Simpler but leaves plaintext around until rotation.
• Update docs/memory/architecture.md to reflect actual state (either correct the "encrypted" claim with the real implementation, or remove it if Option 2 lazy migration).

Acceptance Criteria

• Bot tokens for Slack (both tables) and Telegram are encrypted at rest
• Existing rows migrate cleanly (no service disruption after backend restart)
• Tests cover: create → read round-trip, decryption failure handling, legacy plaintext row migration (if one-shot approach)
• architecture.md credentials section is accurate
• /validate-architecture no longer flags slack_bot_token under Invariant feat: SMARTS trading pipeline with Telegram notifications and Miro visualization #13

References

• Parent issue: Architecture Validation: 4 critical violations found (2026-04-22) #447 (automated architecture validation, 2026-04-22)
• Invariant feat: SMARTS trading pipeline with Telegram notifications and Miro visualization #13: @docs/memory/architecture.md#architectural-invariants
• Existing encryption primitive: src/backend/services/credential_encryption.py

[pavshulin]

/claim

[github-actions]

Claimed by @pavshulin. Label status-in-progress added.

Next steps:

1. Create branch: feature/453-<short-slug>
2. Implement the feature
3. Open a PR with Fixes #453

[pavshulin]

Implementation status — PR #667

PR #667 is open against dev and will close this issue on merge.

Scope refinement vs. the original issue body

The issue body listed three plaintext storage sites; investigation reduced this to one site needing new code plus one site needing a backfill migration:

Original claim	Actual state	Action
slack_link_connections.slack_bot_token plaintext	✅ Confirmed plaintext	New encryption code in db/slack.py + one-shot migration
slack_workspaces.bot_token plaintext	Encrypted on write since rollout, BUT legacy plaintext rows still on disk	One-shot migration re-encrypts in place
telegram_chat_links bot tokens plaintext	❌ Not actually plaintext — bot tokens live in telegram_bindings.bot_token_encrypted, already AES-256-GCM via the same primitive	No code change

Architecture doc said slack_workspaces.bot_token was "encrypted at application layer" — that was only half-true (encrypt-on-write was correct; the legacy backfill claim was aspirational). The migration in this PR makes it true at the row level.

Acceptance criteria

• Bot tokens for both Slack tables encrypted at rest (Telegram already was)
• Existing rows migrate cleanly — verified live: schema_migrations row slack_bot_token_encryption applied 2026-05-05; both DB rows now JSON envelopes
• Tests cover create→read round-trip, decryption failure, and one-shot migration paths (14 tests)
• architecture.md Invariant fix: Add ARM64 Alpine compatibility for frontend Docker build #12 reworded to acknowledge channel/subscription tokens as a documented encryption exception (not a "never stored" claim that was already false)
• slack_link_connections DDL and slack_workspaces DDL annotated with the encrypted-JSON-envelope-in-TEXT-column contract

Note on invariant numbering

Issue title says "Invariant #13"; current architecture.md numbers this rule as #12. The PR description and updated docs use #12.

Follow-up

Encryption test backfill for db/slack_channels.py (SLACK-002), db/telegram_channels.py, and db/whatsapp_channels.py is tracked separately in #664 — they all shipped without dedicated test coverage and adding it retroactively is a clean hygiene ticket separate from this security fix.