[Feature] Add annotation to trigger contiguous slot compaction on a Redkey cluster

### Feature description

## Add annotation to trigger contiguous slot compaction on a Redkey cluster

### Context

Redkey Robin now correctly recovers a Redkey cluster when pods are recreated
while scaling or upgrade operations are in progress. The cluster ends up
well-formed and balanced (each node owns a fair share of the 16384 hash slots).

However, after such a recovery the **slot-to-node distribution is not
contiguous** the way it is on a freshly created cluster. Slots owned by a node
may be scattered across several non-adjacent ranges instead of a single clean
range per node.

This is **not a functional problem** — Redis keeps working correctly regardless
of how slots are laid out. But it becomes a problem for **RDB-based data copy
workflows**: when copying RDB files from one cluster to another, both clusters
must share the **same slot distribution**. A fragmented layout breaks that
assumption and makes file-level RDB copies unusable.

### Proposal

Introduce an annotation on the `Redkey` CR that instructs the
operator/Robin to perform a **slot compaction**: reassign hash slots so that
each node owns a single contiguous range, matching the layout a freshly created
cluster would have.

**Proposed annotation:** `redkey.inditex.dev/compact-slots`

- The operation is **one-shot** (an imperative trigger, not desired state).
- Suggested value: a timestamp or monotonic token (e.g. RFC3339). Applying the
annotation with a new value re-triggers compaction.
- The operator records the last processed value (e.g. in `status`) so an
unchanged annotation does not repeatedly trigger the operation.

### Expected behavior

1. User sets `redkey.inditex.dev/compact-slots: ""` on the Redkey CR.
2. The operator/Robin plans a target layout of contiguous slot ranges,
deterministically distributed across the current master nodes (same rule
used at initial cluster creation).
3. Slots are migrated to reach that target layout using `CLUSTER SETSLOT` /
slot migration, moving data as needed.
4. Once complete, the cluster has a homogeneous, contiguous slot distribution
identical to a freshly created cluster of the same topology.
5. The operator marks the annotation value as processed to avoid re-running.

### Constraints & considerations

- Compaction migrates real data between nodes and can be I/O intensive; it
should run as a controlled, observable operation and be safe to interrupt
(idempotent / resumable).
- Must be mutually exclusive with, or safely queued behind, in-flight scaling
and upgrade operations.
- Should be a no-op if the cluster is already in the canonical contiguous
layout.
- Behavior for clusters with replicas: only master slot ownership is affected;
replicas follow their masters.
- Emit events / status conditions and metrics so operators can observe
progress and completion.

### Out of scope

- Automatic/periodic compaction. This is an explicit, user-triggered action.
- Changing the initial slot-assignment algorithm.

### Acceptance criteria

- [ ] Annotation `redkey.inditex.dev/compact-slots` is recognized on the Redkey CR.
- [ ] Setting a new value triggers exactly one compaction.
- [ ] After completion, each master owns a single contiguous slot range matching
the freshly-created-cluster layout.
- [ ] Operation is safe when concurrent scaling/upgrade is requested (queued or
rejected with a clear condition).
- [ ] No-op when the layout is already canonical.
- [ ] Progress/outcome is observable via events, status conditions, and metrics.
- [ ] Documentation updated (operator guide + CR reference).

### Use case or motivation

_No response_

### Would you like to work on this?

Yes, I'd like to open a PR

Start at the Redkey CR annotation handling and the operator/Robin slot-assignment paths, comparing them with the initial cluster layout and existing scaling or upgrade coordination. Done means the compact-slots value triggers one resumable migration using CLUSTER SETSLOT, records observable progress and completion, handles canonical layouts and concurrency, and updates the operator guide and CR reference.

Written by the indexing model from the issue text.