7f80efc294
Rebasing onto main surfaced three reds in tests/test_tui_gateway_server.py. Two were a real double-check: _run_post_turn_followups already drains the completion queue through _session_owns_notification_event, then handed the events to _notif_handle_ready, which re-ran the belongs-elsewhere and requires-owner gates on every event — a second compression-lineage DB lookup per notification for events the caller had just proven ours. _notif_handle_ready/_notif_handle_event take an explicit owned=True from the post-turn path and skip only the ownership gates (consumed/dedup/turn claiming still run). The poller path is unchanged (owned defaults False). The third, test_run_prompt_submit_requeues_all_unstarted_notifications_with_real_threading, asserted that three consecutive completions produce one in-flight turn plus two requeued events; under this PR's contract (#104671) consecutive completions share one turn, so the first event is now a watch_match — the documented turn barrier — and the test keeps proving that the two completions behind an in-flight notification turn are never lost. A/B: revert the tui_gateway hunks and the two lineage tests fail with ownership_checks recorded twice; restore and all 11 test_run_prompt_submit tests pass.