Additional routing note from user report:

The observed misdelivery may correlate with cron outputs delivered to a Telegram topic (e.g. a farm/cron topic) while a background process from another topic completes later. This PR addresses that failure mode for process completions by making queued completion events self-routable: the event now carries platform/chat_id/thread_id/user metadata from the original process-starting context, and gateway injection reconstructs the synthetic MessageEvent from the event itself rather than any currently active foreground topic.

Cron delivery itself already resolves thread_id from job origin or explicit deliver targets, and cron agent runs intentionally clear HERMES_SESSION_* context so cron ticks do not masquerade as live inbound gateway messages. The added regression test test_completion_event_routes_to_original_telegram_thread covers the key invariant: queued completion notifications route to the original Telegram thread, not whichever thread is active when the queue is drained.

I rechecked this against current origin/main (99ad2d137).

tests/gateway/test_background_process_notifications.py and tests/tools/test_notify_on_complete.py both pass cleanly on current main (49 tests, no failures). The cross-topic routing gap this PR fixes is still present in main — the queue drain at run.py:7651 explicitly skips completion events with the comment 'completion events are handled by the watcher task', but the watcher task doesn't carry thread/session metadata through to the notification call. This PR's approach of routing completions through the same _inject_watch_notification path as watch events is the right fix.

No baseline CI conflicts seen — this PR should merge cleanly.