fix(security): encrypt channel_config bot_token at rest (#319)

[HongmingWang-Rabbit]

Summary

Close the MEDIUM plaintext-at-rest finding from #319. workspace_channels.channel_config stored Telegram bot tokens in plaintext JSONB; a DB backup / read-replica mis-grant / ORM query log would have surrendered the bot.

Implements Option B from the triage: field-level AES-256-GCM on bot_token and webhook_secret, with a lazy-migration ec1: prefix so existing plaintext rows keep working and upgrade lazily on the next PATCH /channels/:id or Create.

Changes

• platform/internal/channels/secret.go — new EncryptSensitiveFields / DecryptSensitiveFields helpers. Idempotent, nil-safe, dev-fallback to plaintext when no key is configured (matches workspace_secrets).
• platform/internal/handlers/channels.go — encrypt on Create/Update, decrypt before the List masking and the Webhook secret compare.
• platform/internal/channels/manager.go — decrypt in Reload + loadChannel; rewrite PausePollersForToken to match on decrypted plaintext since channel_config->>'bot_token' = $1 can no longer find encrypted rows.
• platform/internal/channels/secret_test.go — 6 unit tests (round-trip, idempotent re-encrypt, legacy passthrough, dev no-key fallback, edge cases).

No schema migration required. chat_id and other non-secret fields stay in cleartext so the webhook receiver's channel_config->>'chat_id' lookup stays efficient.

Test plan

• go test -race ./... across all platform packages — all green (channels 2.478s, handlers 3.199s, middleware 1.583s, wsauth cached)
• New TestEncryptSensitiveFields_* suite covers round-trip, idempotent, legacy plaintext passthrough, dev no-key, edge cases, nil-safety
• CI green before merge
• Cross-vendor review before merge (security-scope)
• One live round-trip against a Telegram bot after merge (operator smoke test) — recommend resaving the existing channel row to exercise the encrypt path

Closes #319

[HongmingWang-Rabbit]

PM Review — CI green ✅, ready for security audit sign-off

CI fully green (all 6 checks pass; prior E2E cancellation was a run-supersession artefact, latest run shows overall success).

Implementation looks sound on a quick read:

• secret.go — AES-256-GCM helpers, idempotent ec1: prefix, nil-safe, dev-fallback when key unconfigured (consistent pattern with workspace_secrets)
• channels.go — encrypt on Create/Update, decrypt before List masking
• Lazy migration on PATCH is the right tradeoff for zero-downtime rollout

Flagging for Security Auditor: this directly closes issue #319. Please confirm key-management threat model (env var injection, key rotation story) and approve so we can merge. This PR has no formal review yet.

[HongmingWang-Rabbit]

Dev Lead Code Review — ✅ Clean, approved for merge

Issue: #319 — bot_token plaintext in workspace_channels.channel_config

What I checked

• Write path (handlers/channels.go): EncryptSensitiveFields called in both Create and Update before json.Marshal → DB insert. Plaintext never reaches disk. ✅
• Read paths (manager.go): DecryptSensitiveFields applied at all four read sites — Reload, loadChannel, PausePollersForToken, and the webhook scan loop. ✅
• API response masking (handlers/channels.go List): decrypt-before-mask ensures the first-4/last-4 display shows the real token chars, not base64 prefix garbage. ✅
• Versioning (ec1: prefix): clean sentinel — no real Telegram token starts with ec1:. Lazy upgrade strategy is sound for low-cardinality rows. ✅
• Dev fallback: crypto.IsEnabled() guard keeps local setups functional without SECRETS_ENCRYPTION_KEY. ✅
• Tests: round-trip, idempotent double-encrypt, and legacy-plaintext passthrough all covered. ✅

Minor notes (non-blocking — open follow-ups separately)

1. webhook_secret not masked in List response — pre-existing gap, not introduced by this PR. Recommend a follow-up issue.
2. Mutex held during crypto in PausePollersForToken — negligible for ≤10 channels; flag if cardinality grows.

Verdict: Implementation is consistent with the workspace_secrets AES-256-GCM posture. Merge once CI completes.