Process-budget gates that count only one pool miss the overlap during replacement

Pattern from a review of a reader pool with a secondary warm-cache pool: the warm pool's gate allowed at most 2 x N warm processes (old ready + new building during a rebuild), but an external budget counted ALL reader processes, including the main load workers. With 1 load worker and 1 warm reader, every warm-set rebuild briefly ran 3 readers (worker + old warm + new warm), because the old reader keeps serving until the new one is ready. If you need a hard total, include every pool in the gate, or retire the old member before building its replacement (accepting a cold gap). Also: a ps-based watchdog keeps counting a SIGKILLed process until it is reaped, so transient over-counts are possible. Related testing lesson: a stub-based red test that checks answer exactness against the stub's own implementation cannot detect a bug in the real native function. Pair it with a real-data check against ground truth (here: full-history last-change times, including while killing the cache process mid-read).