fix(gateway): preserve session source and thread metadata across cross-thread interrupts

[x7peeps]

Summary

Two related fixes for gateway/run.py that prevent session routing corruption when a running agent session is interrupted by an inbound message from a different thread or channel.

Closes #47445

Problem

When Hermes is streaming a response in Thread A, and a new message arrives in Channel B (or Thread C), the gateway:

1. Interrupts the running agent
2. Overwrites session_source with the interrupting message's metadata
3. Resumes the session with wrong thread_id/message_id
4. Responses go to the wrong destination (or lose thread routing entirely)

Changes

Fix 1: Preserve original session source (_handle_message_with_agent)

Only cache the session source on first creation - do not overwrite it with the interrupting message's metadata on resume.

Fix 2: Fall back to cached source for thread metadata (_run_agent_via_proxy)

When the interrupting message is a channel-level post (no thread_id), _thread_metadata_for_source() returns None. Fall back to the cached original session source to recover correct thread routing.

Testing

Both patches can be verified on Mattermost with multi-thread workflows: 1. Start a conversation in Thread A (agent streaming) 2. Send a message from Channel B mid-stream 3. Verify the original session resumes with correct thread routing 4. Verify subsequent messages in Thread A still route to Thread A

[alt-glitch]

Duplicate of #47458 — both fix #47445 (cross-thread interrupt corrupting session source/thread routing) in gateway/run.py with the same two changes: (1) only cache the session source when absent so a resume does not overwrite it, and (2) fall back to the cached source for thread metadata when the interrupting (channel-level) message has no thread_id. #47458 (earlier, with test coverage) extracts these as helpers; this PR inlines the identical logic. Marking duplicate of the earlier open PR.

[teknium1]

Closing along with #47445 — after tracing the issue's mechanism against current main, the described cross-thread session-source corruption can't occur: build_session_key() embeds thread_id, so a message from a different thread/channel lands in a different session and never touches the running session's source. The fallback-to-cached-source half is already on main via #21206. Full trace in #47445 (comment) (closing comment there).

Appreciate the clean implementation and tests — the premise just doesn't hold on current main. If you can reproduce wrong-thread delivery on a current build, please comment on #47445 with a gateway.log excerpt.