feat: bridge Desktop approvals to Telegram

[jamesdgreenfield-spec]

Summary

• add an opt-in, profile-local bridge that mirrors Desktop dangerous-command approval prompts to Telegram
• resolve the exact authoritative Desktop approval request from authenticated Telegram buttons
• mirror only allowlisted generic Desktop background-process status notifications
• preserve local Desktop approval behavior and legacy FIFO responses for callers without request IDs

Security model

• tools.approval remains the sole command-execution authority; Telegram and SQLite transport authenticated intent only
• cryptographically random opaque request IDs, canonical expiry, allowed-choice validation, single-use decisions, and replay rejection
• callbacks are bound to authorized Telegram user plus delivered chat, topic/thread, and message ID
• Telegram reports approval only after the Desktop-side authoritative queue acknowledges the exact request
• timeout, interrupt, notifier-failure, local-click, and shutdown arbitration are atomic and fail closed
• approval command/description are redacted before persistence; process command, output, watch patterns, and arbitrary event text are rejected
• profile-specific HERMES_HOME context is preserved across resolver threads
• SQLite uses WAL fallback handling and restrictive database/WAL/SHM permissions
• unsupported non-Telegram targets fail closed

Configuration

Disabled by default:

approvals:
  cross_surface:
    enabled: true
    target: telegram
    process_notifications: true

Validation

• affected Python suite: 866 passed, 2 known baseline tests deselected
• Desktop Vitest: 35 passed
• Desktop TypeScript typecheck: passed
• Desktop ESLint: passed
• Ruff: passed
• Python compilation: passed
• diff checks: passed
• separate-context security review of rebased commit: PASS, no findings

Live verification

Tested on macOS with a rebuilt Desktop app and launchd-supervised Telegram gateway:

1. Desktop emitted a real approval for a contained recursive deletion under /tmp.
2. Telegram delivered the exact approval with buttons.
3. An authorized once decision resolved the matching Desktop queue entry.
4. Desktop executed the command only after authoritative acknowledgement.
5. Filesystem checks confirmed the expected contained deletion.
6. A bounded Desktop background process produced the generic Telegram notification Desktop background process completed (exit code 0).
7. The bridge payload contained no raw command, process output, watch pattern, or Desktop session key.

[teknium1]

Thanks for the security-focused, opt-in implementation. The feature is not already present on current main: Desktop approval responses are still session-keyed FIFO in tui_gateway/methods_prompt.py:864-883, and approval.request carries no request ID in apps/desktop/src/app/session/hooks/use-message-stream/gateway-event.ts:887-907.

Problems

• GitHub currently reports this PR as CONFLICTING. Current main has moved the active approval RPC to tui_gateway/methods_prompt.py:864-883 and changed overlapping TUI/Desktop/Telegram files after the PR base, so the patch needs an integration pass rather than a clean cherry-pick.

Suggested changes

• Port the targeted request-ID path onto the current methods_prompt.py handler and current Desktop approval store/event flow, while preserving the existing FIFO compatibility path for older runtimes.
• Preserve current-main's approval redaction seam at tui_gateway/server.py:1592-1611 and Telegram callback authorization checks at plugins/platforms/telegram/adapter.py:6251-6261 during conflict resolution.

Automated hermes-sweeper review.