Add listpack ZINCRBY coverage (1M small sorted sets, same-member increment)

[fcostaoliveira]

Our current ZINCRBY coverage (memtier_benchmark-1key-zincrby-1M-elements-pipeline-1) runs against a single 1M-element skiplist+hashtable-encoded sorted set. There is no coverage for the listpack-encoded small-zset ZINCRBY update path — the find → delete old (member,score) → reinsert sequence in zsetAdd() for sets within zset-max-listpack-entries.

This adds memtier_benchmark-1Mkeys-zincrby-16-elements-listpack-pipeline-10: 1,000,000 keys, each a 16-member listpack-encoded sorted set, repeatedly ZINCRBY -P 10 on an existing member. It scales out the small-listpack ZINCRBY workload reported in redis/redis#15288 (single-member increment) across 1M keys to avoid single-key cache-hot artifacts, giving server-class coverage for the listpack same-member update path.

Encoding is pinned via zset-max-listpack-entries 128 / zset-max-listpack-value 64; 16 members per key stays comfortably listpack.

---

Note

Low Risk
Only adds a benchmark YAML definition; no application or Redis server code changes.

Overview
Adds a new memtier benchmark suite memtier_benchmark-1Mkeys-zincrby-16-elements-listpack-pipeline-10 so CI can stress ZINCRBY on listpack-encoded sorted sets (16 members per key, 1M keys), with ZINCRBY -P 10 on an existing member.

The suite preloads via ZADD, pins listpack encoding with zset-max-listpack-entries / zset-max-listpack-value, and targets the same-member update path in zsetAdd() that prior ZINCRBY coverage on a single huge skiplist zset did not exercise. It is meant to catch regressions like those discussed in redis/redis#15288 without single-key cache-hot bias.

^{Reviewed by Cursor Bugbot for commit 2f86487. Bugbot is set up for automated code reviews on this repo. Configure here.}