Module pool 

Pool-related reducer handlers. Extracted from reducer/mod.rs in task #182 PR-B for navigability.

Functions

handle_report_host_pool_count 🔒

Phase B.4 follow-up — pool-only drift check. Called from spawn_pool_window where the windows dimension is mid-flight (close path hasn’t completed). Compares only the pool dimension; emits DriftDetected { kind: Pool, ... } on mismatch.

handle_report_pool_drain_decision 🔒

Phase F.6 — host-emitted signal carrying the result of the post-close drain-pool-if-last decision. Maps was_last directly to the corresponding terminal event for Step 2 of the window-cleanup-cascade saga:

handle_report_pool_window_added 🔒

Phase B.4 follow-up — record pool inventory growth. Idempotent on duplicate labels (HashSet semantics) but the event still fires so subscribers can track add-attempts even if redundant.

handle_report_pool_window_promoted 🔒

Phase F.5 — host-emitted promote signal. The reducer doesn’t mutate state for this command (the windows/pool transitions are carried by the surrounding ReportPoolWindowRemoved + ReportWindowOpened pair); it just translates the wire command into the corresponding typed event so subscribers — most importantly the launcher saga coordinator — can react.

handle_report_pool_window_removed 🔒

Phase B.4 follow-up — record pool inventory shrink (promote or destroy). Strictly paired with ReportPoolWindowAdded: an unknown-label remove is a silent no-op so subscribers can rely on add/remove pairing in the broadcast stream. Same gate as handle_report_window_closed. (reagent P2 PR #577 round-3 — the original “idempotent” comment referenced behavior that was already removed for ReportWindowClosed; pool semantics now match.)