hermes - 💡(How to fix) Fix TUI: background process completion notifications can route to the wrong live session [2 pull requests]

Bug Description

In hermes --tui, background process completion notifications can be delivered to the wrong live TUI session when multiple live sessions exist in the same TUI process.

Example notification shape:

[IMPORTANT: Background process proc_... completed (exit code 0).
Command: ...
Output:
...
]

The notification should be routed back to the TUI live session that started the background process. Instead, it can appear in whichever TUI session's notification poller drains the global completion queue first, including the session the user is currently viewing.

This is a follow-up class to #15248 / #26071: TUI no longer silently drops notify_on_complete notifications, but multi-live-session routing is not owner-scoped.

Steps to Reproduce

1. Start hermes --tui.
2. Open or create two live TUI sessions, A and B (Ctrl+X / /sessions).
3. In session A, ask the agent to run a long background process with terminal(background=true, notify_on_complete=true), e.g. a long download or sleep 30 && echo done.
4. Switch to session B before the process exits.
5. Wait for the background process to complete.

Expected Behavior

The [IMPORTANT: Background process ... completed] notification should be injected/rendered in session A, the session that created the process.

Session B should not receive that notification, and B's transcript should not be polluted by process output from A.

Actual Behavior

The completion notification can appear in session B (or another unrelated TUI live session), depending on which per-session poller consumes the event first.

Root Cause / Code Pointer

tui_gateway/server.py::_notification_poller_loop() starts one poller per TUI session, but all pollers drain the same global process_registry.completion_queue.

The local source currently documents the race in a comment:

# The completion_queue is global (one per process). If multiple
# TUI sessions coexist, whichever poller wakes first grabs the event,
# even if the process was started by a different session.

The event is then emitted using the poller's sid, not necessarily the owner session that started the background process.

Related Issues

• #15248 — TUI notify_on_complete silently drops notifications
• #26071 — duplicate of #15248; identifies missing TUI completion_queue drain
• #9532 — similar wrong threaded-session leakage class
• #10411 — Discord watch_match wrong-thread leakage
• #18101 — Slack background process wrong-thread leakage

Proposed Fix

Make TUI background-process notification routing owner-scoped:

1. Record the originating TUI sid or stable session_key when a background terminal process is created.
2. Carry that owner id in completion/watch events.
3. Replace per-session queue consumers with a single central TUI notification router, or make per-session pollers ignore/requeue events whose owner is not their session.
4. Inject/render the notification only into the owner session.

Environment

• Repo: NousResearch/hermes-agent
• Mode: modern TUI (hermes --tui)
• Local source file observed: tui_gateway/server.py
• Observed in a TUI with multiple live sessions in the same terminal process