fix: resolve conflicting slot claims by config epoch

[kacy]

Every gossip ping carries the sender's slot claim, and receivers applied whichever claim they saw last. The claim's incarnation only orders updates from one node. It can't settle two nodes claiming the same slot. After a failover, the old primary coming back kept announcing its old slots, so peers moved them back and forth between it and the promoted replica.

Claims now carry the claiming node's config epoch, as in Redis Cluster.

Wire format:

• SlotsChanged, SlotsAnnounce and MemberInfo gain a config_epoch.
• The gossip engine tracks each member's epoch and sends the local node's epoch with its slots.

Conflict rule, in ClusterState::apply_slot_claim:

• A claimed slot goes to the claimant when it is unowned, or when the claim beats the owner's: a higher epoch, or an equal epoch and a higher node ID, so every node picks the same winner.
• Slots the claimant owned and no longer claims become unowned.
• The cluster's current epoch rises to the claim's epoch. A replica has therefore seen its primary's epoch, and the epoch it takes when promoted is newer.

Server:

• Gossip SlotsChanged and MemberJoined go through apply_slot_claim instead of assigning slots directly.
• When a newer claim takes slots from the local node, it logs a warning and re-announces its reduced slot list, so it stops claiming them.
• CLUSTER SETSLOT <slot> NODE <self> bumps the local epoch (bump_local_epoch), as Redis does. Without this, the previous owner's claim would win until it heard about the move.

This changes the gossip wire format, like #388 did, so the nodes of a cluster need to be upgraded together.

Tests cover a newer claim taking slots and raising the epoch, a stale claim losing, slots dropped from a claim, the tie-break, and the epoch bump.