fix(server): the count-triggered self-merge takes the worker's merge slot

[beinan]

Problem

ROLLOUT_MERGE_AFTER_GENERATIONS is the pending-driven merge trigger: when a worker's own shard has ≥ N flushed generations, the 30 s flush sweeper merges it. That is exactly what hot stores need (a store written every few seconds regrows hundreds of generations between the master's 600 s sweeps, and every read has to open all of them — 8–13 s per read on a 176-generation store today).

But that sweeper merge bypassed the per-worker merge slot (ROLLOUT_MERGE_CONCURRENCY, #278). Enabling the count trigger would stack sweeper merges on top of the master's merge requests with no memory bound.

Fix

flush_pass takes the worker's merge-slot semaphore and acquires a permit around merge_if_due, so sweeper-initiated and master-initiated merges share one bound. No behaviour change while the count trigger is 0 (the default and current production value).

Verification

Server suite passes (85); clippy clean. Production enablement is a config change in the deployment repo (ROLLOUT_MERGE_AFTER_GENERATIONS=64), validated on staging first.

🤖 Generated with Claude Code

[beinan]

Addressed: the pass now try_acquire_owned()s the slot and skips the self-merge when all slots are busy (counted as rollout_wal_self_merge_skipped_total), so flushing of later stores is never blocked — including with the trigger at 0. Added flush_pass_never_waits_on_a_busy_merge_slot (two stores, trigger off, slot held → both flush, nothing merges) and flush_pass_merges_when_a_slot_is_free.