test(gateway): stop a leaked notification poller stealing the next test's events

[OmarB97]

What does this PR do?

tests/test_tui_gateway_server.py fails intermittently under load, always in the same family:

FAILED test_run_prompt_submit_requeues_all_unstarted_notifications_with_real_threading
FAILED test_run_prompt_submit_requeues_foreign_completion[0]
FAILED test_notification_poller_live_loop_requeues_foreign_completion_for_owner

The cause is a leaked thread, not a product bug. _start_notification_poller spawns a daemon thread that loops until its session is finalized:

while not stop_event.is_set() and not session.get("_finalized"):
    evt = process_registry.completion_queue.get(timeout=0.5)

Four tests in this file register a session straight into server._sessions and pop it again without going through _teardown_session, so _finalized is never set and _notif_stop is never fired — the poller runs for the rest of the pytest process:

• test_session_resume_profile_uses_profile_db_cwd
• test_init_session_fires_reset_hook
• test_session_create_no_race_keeps_worker_alive
• test_session_create_continues_when_state_db_is_unavailable

By the time the notification tests run, four are live. process_registry.completion_queue is process-wide and the loop re-reads the attribute every iteration, so when a later test monkeypatches an isolated Queue in, the leaked pollers see it too and compete for its events.

Reproduced deterministically — one leaked poller, one poll cycle, and the event a test expected to still be there is gone:

leaked = _sess("leaked-session")
server._sessions["leaked-sid"] = leaked
server._start_notification_poller("leaked-sid", leaked)
server._sessions.pop("leaked-sid", None)      # no _teardown_session -> no _finalized

isolated = queue.Queue(); isolated.put(event)
monkeypatch.setattr(process_registry, "completion_queue", isolated)
time.sleep(0.7)                                # one poll cycle
assert isolated.qsize() == 1                   # FAILS: qsize is 0

Depending on where the leaked poller's own session sits, the event is dropped as unowned, or bounced out and re-queued 0.1s later, or simply held past the test's deadline. All three land as the failures above, which is why they only show up when the machine is busy enough for the poller to win the race.

This is test-only. Production has no equivalent path: every _pop_session_by_id is immediately paired with _teardown_popped_session → _teardown_session → _finalize_session, which sets _finalized and fires the stop event. No product code is changed here.

Related Issue

No issue — found while verifying #333, where this family failed once in a contended run and again on an unmodified tree at -j 8.

Type of Change

• ✅ Tests (adding or improving test coverage)

Changes Made

• tests/conftest.py — new opt-in reap_notification_pollers fixture. It wraps _start_notification_poller, records the stop event, session and thread for each poller a test starts, and at teardown sets both brakes (_finalized and the event) and joins the thread. Joining is the point: setting the event alone still leaves the poller parked in a 0.5s queue.get(), long enough to take one more event off the next test's queue. It asserts nothing survived. Not autouse — it takes the shared monkeypatch so a test patching the same attribute unwinds in the right order, and per tests/conftest.py's own note, intra-file ordering is the test author's job.
• tests/test_tui_gateway_server.py — opt in via pytestmark, next to the existing _neuter_agent_prewarm_timer fixture that solves the same class of problem (one test's background thread landing in the next test's assertions).
• tests/test_tui_gateway_server.py — new test_a_started_notification_poller_does_not_outlive_its_test, which leaks a poller on purpose so the reaping path runs on every CI pass. If reaping regresses it fails there by name, instead of resurfacing as a load-dependent flake somewhere else.
• Corrected the now-stale tolerance comment in test_run_prompt_submit_requeues_all_unstarted_notifications_with_real_threading, which told the next reader that leaked pollers stealing from this queue was legitimate.

tests/tui_gateway/test_review_summary_callback.py leaks three pollers the same way but is deliberately left alone: it has no queue-sensitive tests, and its server fixture must be the first thing in the process to import tui_gateway.server (it imports under a patched sys.modules), which requesting this fixture would break.

How to Test

pytest tests/test_tui_gateway_server.py -q

• Before: with a plugin that counts live _notification_poller_loop threads, the total climbs 1 → 2 → 3 → 4 across the run, and the file fails intermittently.
• After: the total never exceeds the poller belonging to the test currently running, and the file passes (390 tests).
• Break the reaper on purpose (drop the stop.set()) and the new guard test fails in teardown with notification poller thread(s) still running: ['Thread-5 (_notification_poller_loop)'].

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix
• I've run the affected suites and they pass (tests/tui_gateway, tests/test_tui_gateway_server.py, tests/test_profile_isolation_runtime.py, tests/tools/test_process_registry.py)
• I've added tests for my changes
• I've tested on my platform: macOS 15 (Darwin 25.6.0)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — N/A (test-only; the fixture and comments carry the rationale)
• I've updated cli-config.yaml.example if I added/changed config keys — N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact — N/A (stdlib threading only)
• I've updated tool descriptions/schemas if I changed tool behavior — N/A