perf: N-shard CLUSTER SLOTS projection + MOVED = hop eliminated (#517 PR4)

[ELares]

What (the #517 milestone)

A shard-owners node now boots the N-shard projection instead of single-node-owns-all: N synthetic cluster nodes, node i at (advertised_host, base_port + i) owning the contiguous slot range shard_slot_range(i, N) -- the same slot_to_shard partition the internal router uses.

• CLUSTER SLOTS / SHARDS / NODES advertise N owners at N ports (fully map-driven -- zero command-layer changes); CLUSTER INFO reports cluster_size:N, all 16384 slots assigned, state:ok.
• A cluster-aware client dials each key's owner port -> the connection homes on the owning shard (PR3 listeners) -> owner_shard(key,N) == home.index -> the request takes the local fast path with no cross-shard hop. The hop is eliminated.
• A key sent to the wrong port gets -MOVED <slot> host:base+owner, so clients converge to zero hops.

Mechanism (per the recorded design)

Thread the home ShardId into the redirect: in shard-owners mode moved_if_unowned decides ownership by the contiguous partition (slot_to_shard(slot, home.total) == home.index) -- the identical predicate the hop uses, so the two can never disagree. No per-shard SlotMap duplication (one shared display map); Static/Raft pass home_owner = None and are byte-unchanged.

Also fixes a latent MOVED-target bug: a 0.0.0.0/:: bind is not dialable, so the advertised host falls back to loopback (shard_owner_announce_host). synth_node_id is made pub for the synthetic per-shard ids (node 0 = the announce id = self, so CLUSTER MYID is stable).

Tests

• owner_port_serves_locally_and_a_misrouted_key_gets_moved (the milestone assertion, 7 keys x 4 shards): owner port -> +OK/value with no MOVED; wrong port -> -MOVED pointing at the exact owner port.
• cluster_info_reflects_the_n_shard_projection (size:4, 16384 assigned, state:ok), N=1 single-node (never MOVED), per-shard liveness; PR2/PR3 tests updated for the owns/MOVED semantics.
• Regression: cluster_countkeysinslot + cross_shard_pipeline + 272 ironcache-lib + 573 ironcache-server tests pass unchanged; clippy -D warnings (tokio + io_uring) + fmt + invariant lints clean.

Behavioral note (intentional, standard Redis Cluster semantics): a plain non-cluster client pinned to one port is served only for the keys that port owns and gets MOVED for the rest -- exactly how a real Redis Cluster node behaves. Cluster-aware clients (redis-cli -c, every cluster driver) handle this transparently.

Ref #507, #517. Next (PR5, final): driver-matrix cluster leg + zero-hop metric assertion + docs.

🤖 Generated with Claude Code

[github-actions]

perf-gate (A5)

Same-runner ratchet of HEAD against the merge-base (both rebuilt and measured in this job).
PASS = within the noise band, WARN = a real move inside budget (does not fail), FAIL = past budget in the bad direction.

metric	base	head	delta%	band	budget	verdict
qps_median (peak)	97375.99	97696.30	0.33%	+/-5.00%	drop <= 15%	PASS
bytes_per_key int	45.02	45.02	0.00%	det	rise <= 5%	PASS
bytes_per_key embstr	61.07	61.07	0.00%	det	rise <= 5%	PASS
bytes_per_key raw	333.15	333.15	0.00%	det	rise <= 5%	PASS

Overall: PASS

• qps: noisy on shared CI, so the band comes from the base reps spread (floored at 5%); a drop is only a regression past the 15% budget.
• bytes_per_key: deterministic (allocator-true memmodel), so a tight 5% rise budget; any rise beyond it FAILs.
• Open-loop tails / criterion micro-benches are reported-not-failed (tail noise is high) and are not part of this ratchet.
• An intentional perf trade is landed by raising the relevant budget in this PR with a documented reason (CI never auto-commits a baseline).

[ELares]

Deep self-review: verdict CORRECT (routing core), two peripheral findings addressed

The adversarial review confirmed the milestone mechanics end to end: the slot math is proven (shard_slot_range is the exact inverse of slot_to_shard; no underflow for any n <= 256), home.total always equals the projection's N (both derive from config.shards.max(1)), moved_target(slot) always returns the slot's owner node at base+owner, Static/Raft paths are byte-unchanged (home_owner = None at every call site), in-MULTI foreign keys MOVED-dirty the txn per Redis semantics, CROSSSLOT fires before any fan-out, and the IPv6 MOVED format follows the raw host:port Redis convention. Nothing misroutes data.

Findings addressed:

1. Port-block validation (fixed): port .. port + shards - 1 was unvalidated, so an overflowing config hit a boot panic in the projection build, pre-empting PR3's graceful bind error. Config::validate (new validate_shard_owners helper) now rejects it with one clean error; boundary tests added (65500+100 rejected; 65532+4 = top port exactly 65535 accepted).
2. Whole-keyspace divergence (documented + tracked as shard-owners: scope whole-keyspace commands (KEYS/SCAN/DBSIZE/RANDOMKEY/FLUSH) to the connecting shard for Redis Cluster parity #526): KEYS/SCAN/DBSIZE/RANDOMKEY/FLUSH* are redirect-exempt and fan out across all shards from any port, so per-node cluster aggregators over-count by N vs real Redis Cluster. Documented as a KNOWN DIVERGENCE in the CHANGELOG. The clean fix is natural post-perf: align the internal shard owner to the CRC16 cluster slot (#517 PR1) #520 (shard i's store holds exactly its slot range, so home-only answering gives exact parity) but changes SCAN cursor semantics, deserving its own PR + tests: shard-owners: scope whole-keyspace commands (KEYS/SCAN/DBSIZE/RANDOMKEY/FLUSH) to the connecting shard for Redis Cluster parity #526 with full acceptance criteria. The review's informational note (SPUBLISH broadcasts globally, pre-existing superset-delivery fidelity gap) is folded into shard-owners: scope whole-keyspace commands (KEYS/SCAN/DBSIZE/RANDOMKEY/FLUSH) to the connecting shard for Redis Cluster parity #526.

Merging on green.