Bug Description

Background process progress/output notifications can be delivered into the wrong Slack thread.

I hit this during normal Hermes use in Slack: a background process that had been started from one Slack thread later posted its synthetic progress message into a different Slack thread.

The leaked message looked like this shape:

[Background process proc_6f65d5261750 is still running~ New output:
...process log lines...
]

In this case, the user in the current thread explicitly noticed that the output belonged to another Slack thread.

This is a cross-thread routing leak, not just noisy logging.

Steps to Reproduce

1. In Slack thread A, start a background process with automatic progress updates enabled (for example via terminal(background=true, check_interval=30) or another path that emits automatic running-process updates).
2. Leave that process running long enough to produce later output.
3. In Slack thread B, continue chatting with Hermes.
4. Wait for the background process from thread A to emit another update.
5. Observe that the synthetic background-process update can appear in thread B instead of the original thread A.

Expected Behavior

• Background process updates should be routed only to the original Slack thread/chat/session that started the process.
• A process started in thread A should never inject progress output into thread B.

Actual Behavior

• A synthetic background-process update from one Slack thread appeared in a different Slack thread.
• The injected text included the process session id and raw log lines, making the leak obvious to the user.

Impact

• Cross-thread leakage of tool/process output between unrelated Slack conversations
• User confusion and loss of trust
• Possible exposure of context/logs from one thread into another thread

Environment

• Platform: Slack
• Session type: threaded Slack conversations
• Process pattern involved: automatic background-process progress updates

Related Issues

• Similar shape to Discord cross-thread watch notification leak: [Bug]: Background watch_match notifications can be injected into the wrong Discord thread #10411
• Possibly related to background process notification routing / dedup paths: Background process completion and watch notifications can duplicate #15276

Suspected Root Cause

Likely the routing metadata for automatic background-process updates is not being preserved all the way through delivery, and the notification is instead being injected using the currently active event/thread context.

That would mirror the same family of bug as #10411, but for Slack background-process progress output rather than Discord watch-match notifications.

Proposed Fix

• Store original routing metadata with the background process / notification event (platform, chat_id, thread_id, session key, etc.)
• Deliver automatic process updates using that stored routing metadata only
• Add a regression test that starts a process in Slack thread A, sends a normal message in Slack thread B, then verifies the next process update still lands in thread A