[Fix] Give Discord its own gateway secret (Telegram-style)

[roomote-roomote]

Opened on behalf of Matt Rubens. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

Related issue

Security hardening from P1 Discord gateway auth review (no public issue link).

Why this PR exists

• A maintainer explicitly invited this PR in the linked issue or discussion
• I am a maintainer / this is internal Roomote work

What changed

Discord gateway↔API auth uses only a dedicated R_DISCORD_GATEWAY_SECRET.

• API + Discord gateway resolve that secret from process env or the encrypted deployment vault
• Saving Discord credentials auto-generates the secret when missing (Telegram-style)
• Gateway polls for the secret and starts/restarts delivery when it appears (no BullMQ restart required after first Discord save)
• Local development writes one shared default into process.env so API and gateway match
• Installers, upgrades, and deploy templates generate and share the secret for env-only fleets
• Operator docs require the gateway secret to be dedicated (not ENCRYPTION_KEY)
• Timing-safe compare is unchanged

Why this change was made

Gateway event injection and secret-at-rest protection should not share a key. A dedicated transport secret is generated when Discord is configured, matching how Telegram already handles its webhook secret.

Impact

• New Discord UI saves create a dedicated transport secret automatically and can begin forwarding without a service restart
• Manual env setups are told not to reuse the vault key
• Env-only deployments get the secret from install/upgrade/template paths

How it was tested

• Discord auth + gateway unit tests
• Pre-push suite on push

Checklist

• The PR title follows the repo convention
• This PR is small and scoped to one change
• pnpm lint and pnpm check-types pass locally
• I added tests or included a clear manual validation note above
• I removed secrets, tokens, private keys, and customer data from code, logs, and screenshots
• If this change should appear in the changelog, I ran pnpm changeset

[roomote-roomote]

No new code issues found. See task

• High: Preserve Discord forwarding on supported upgrades
• Medium: Add the gateway secret to the manual Production Compose setup
• Medium: Restore the distinct-key requirement in operator docs
• High: Retry the generated gateway secret after UI configuration
• Medium: Use one local-development secret source in API and BullMQ
• Medium: Do not restart delivery after leadership is lost — fixed in c83aeaf (lease checks around delivery restart + early poll exit)

_{Reviewed c83aeaf}

[roomote-roomote]

Addressed the open leadership race in c83aeaf:

• ensureDeliveryLoop re-checks leaseValid / stopped after any await and before starting a new forwarder
• the credential poll exits early once the lease is lost so a former leader cannot spawn concurrent delivery while shutting down

No review threads to resolve (feedback lived in the top-level summary checklist).