[beinan]

A maintenance master with MERGE_WAL_INTERVAL_SECS=0 still consumes queued MergeWal tasks. Setting MERGE_WAL_CONCURRENCY=0 does not disable them either: it folds them into the general pool. In production, an older maintenance executor repeatedly claimed merge tasks and failed at the first unavailable worker, while retaining its compact/index role.

Add MASTER_CLAIM_WAL_MERGES=false (--claim-wal-merges=false) to opt a master out of scheduler MergeWal claims. The default remains true. It covers shared/general, dedicated RPC and resident merge pollers; Compact, IndexId and Repair continue using their existing queues. Merge tasks remain available to other executors. This does not cancel accepted tasks, change enqueue sweeps or ownership, or provide a drain mechanism for an already-running old binary.

Validation: formatting and diff checks pass. The real isolated-etcd regression passed in all three configurations (shared, dedicated and resident): compact/index complete while MergeWal remains durably queued and unclaimed, then another executor claims it. Five additional regressions passed: CLI/default parsing, default merge admission, compaction progress with a saturated merge pool, reserved resident progress with a saturated legacy pool, and drain preserving accepted work while leaving queued tasks for peers. Clippy CI and all three wheel builds passed; remaining test/coverage CI is running. No production configuration changes are part of this PR.