test(gateway): stop the review-summary tests leaking notification pollers too

[OmarB97]

What does this PR do?

Finishes the notification-poller leak that #335 started. That PR fixed tests/test_tui_gateway_server.py and explicitly left tests/tui_gateway/test_review_summary_callback.py alone; this closes it.

Three tests there call server._init_session(...), which starts a notification poller. The module's server fixture cleans up with:

mod._sessions.clear()

Clearing the registry does not stop a poller. The loop only breaks on _finalized or its stop event, and both are set by _teardown_session, which the fixture never calls — so each of the three tests leaves a daemon thread polling the process-wide process_registry.completion_queue for the rest of the run. With a plugin that counts live _notification_poller_loop threads, the total climbs 1 → 2 → 3 across the file.

Nothing in this file is queue-sensitive today, which is why #335 could defer it. It is still a leak worth closing: the queue is process-wide, so the blast radius is whatever runs next in the same process, and it is the exact shape that produced the load-dependent failures #335 fixed.

Why it couldn't just use the fixture from #335

reap_notification_pollers does from tui_gateway import server at fixture setup. This module's server fixture must be the first thing in the process to import tui_gateway.server — it imports it inside a patch.dict("sys.modules", ...) that swaps in mocked hermes_constants and hermes_state, and that patch only has any effect on the first import. A fixture that imported the module at setup would silently change what these tests exercise.

So the reaping is split out of reap_notification_pollers into a notification_poller_reaper factory fixture that takes the module you already imported:

def server(notification_poller_reaper):
    with patch.dict("sys.modules", {...}):
        mod = importlib.import_module("tui_gateway.server")
        notification_poller_reaper(mod)     # <- track from here on
        yield mod

reap_notification_pollers is now a two-line wrapper over the same factory, so both paths share one implementation and one teardown contract: set both brakes, join the thread, assert nothing survived. No behavior change for test_tui_gateway_server.py.

Related Issue

Follow-up to #335 (the deferred half, called out in that PR's body).

Type of Change

• ✅ Tests (adding or improving test coverage)

Changes Made

• tests/conftest.py — extract notification_poller_reaper, a factory fixture yielding track(server_module); reimplement reap_notification_pollers on top of it. Patching still goes through the shared monkeypatch, so a test patching the same attribute unwinds in the right order and can't leave the wrapper installed.
• tests/tui_gateway/test_review_summary_callback.py — the server fixture takes notification_poller_reaper and calls it right after its own import, with a comment recording why it can't use the module-wide fixture.

No product code changes. Production still has no equivalent path: every _pop_session_by_id is paired with _teardown_popped_session → _teardown_session → _finalize_session.

How to Test

pytest tests/tui_gateway/test_review_summary_callback.py -q

• Before: live _notification_poller_loop threads accumulate 1 → 2 → 3 across the file and all three survive it.
• After: the count never exceeds the poller belonging to the running test, and the factory's teardown assertion (notification poller thread(s) still running: [...]) fires if reaping ever regresses — the three _init_session tests exercise that path on every run.
• The import-order property is preserved: the fixture still performs the first tui_gateway.server import inside its patch.dict, and the reaper imports nothing but threading.

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)
• I've added tests for my changes — N/A, this is a test-hygiene fix; the factory's teardown assertion is the guard and the three existing _init_session tests drive it
• 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 docstrings 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