[mgravell]

Implements the Redis 8.12 BITRANGEINTARRAY command (redis/redis#15986, part of the native bitmap work in redis/redis#15331). The plan is in notes/bitrangeintarray/plan.md; the implementation follows it.

API

// IDatabase / IDatabaseAsync, [Experimental(Experiments.Server_8_12)]
long[] StringBitPositions(RedisKey key, bool bit, long start = 0, long end = -1,
    StringIndexType indexType = StringIndexType.Byte, long? limit = null,
    CommandFlags flags = CommandFlags.None);

// RedisFeatures
bool StringBitPositions => Version.IsAtLeast(v8_12_0);

The enumerating sibling of StringBitPosition (BITPOS): same key, bit, start, end, indexType shape and defaults, with limit added before flags. bit: false sends ZEROS; StringIndexType.Bit sends BIT, and the default BYTE is omitted exactly as BITPOS/BITCOUNT do. Negative limit throws client-side. The reply is a flat integer array, so ResultProcessor.Int64Array is reused, and the argument tail fits an existing Message.Create overload: no new types, no new processor. Replica-eligible, from the READONLY flag. The XML remarks carry the paging rule (BIT: next start is last + 1; BYTE: the server completes the byte, next start is last / 8 + 1).

Verified

• dotnet build Build.csproj -c Release /p:CI=true clean.
• RoundTripUnitTests.BitPositionsRoundTrip: exact wire bytes for every option combination, LIMIT 0, and the two client-side argument checks.
• BitTests.StringBitPositions_* (ranges, clear bits, limit, paging without gaps in both units, missing key and WRONGTYPE), gated Create(require: RedisFeatures.v8_12_0): green on RESP2 and RESP3 against a local build of unstable at 6a5fee67, which reports redis_version:255.255.255 (and originally skipped on the docker topology).
• Earlier, the server PR's examples were checked by hand against the same build for both a string bitmap and a native bitmap-roaring one; the plan records them as observed.
• 8.12 RC2 (2026-11-03): RedisFeatures.v8_12_0 is now pinned to 8.11.241, which is what RC2 reports — the 8.12.0 placeholder would have made the gated tests skip on RCs. The docker topology / CI default image is now redislabs/client-libs-test:8.12-rc2, with cluster-bus-port-protected-mode no added to the test cluster configs (RC2 introduces that check and otherwise refuses to start a plaintext cluster node). All StringBitPositions live and round-trip tests pass against the RC2 topology; the wire syntax (key start end [BYTE|BIT] [LIMIT n] [ZEROS], set bits by default) and the missing-key/WRONGTYPE behaviour are unchanged on RC2.

Shared with #3261 (BLESS)

Both are 8.12, so this adds the same gating pieces with identical text: Experiments.Server_8_12 = "SER011", the SER011 NoWarn entry, RedisFeatures.v8_12_0 (pinned to 8.11.241, the RC2 version), and docs/exp/SER011.md. Whichever lands second merges textually, except the feature list in docs/exp/SER011.md, which needs both bullets.

Also

• Deletes the BITRANGEINTARRAY row from docs/CommandCoverage.md; the audit script reconciles.
• Deferred, as in the plan: a Lease<long> variant for dense bitmaps, and an IAsyncEnumerable<long> paging helper.

RC2 ZSCAN duplicates (server behavior change, handled)

The only CI failures on the RC2 image are the 8 ScanTests.SortedSetScanLarge cases (all page sizes, RESP2+RESP3): a full ZSCAN iteration over a stable 2000-element sorted set returns 2001-2003 entries, with a few members duplicated. Reproduced with pure redis-cli against redislabs/client-libs-test:8.12-rc2 (deterministic per dataset; ZCARD is 2000, distinct members 2000), clean on redis:8.2, and HSCAN/SSCAN are unaffected — a ZSCAN behavior change in the 8.12 btree zset encoding, reported upstream as redis/redis#16158. SortedSetScanLarge now asserts the distinct member count, so CI is expected green; revisit if redis/redis#16158 is fixed before GA. Everything else was already green (6700+ tests).