Fix BITOP failures in MULTI/EXEC transactions (#1954)

[vazois]

Description

Fixes #1954 — BITOP commands fail inside MULTI/EXEC transactions.

BITOP is parsed as a subcommand-style command: the operation token (AND/OR/XOR/NOT/DIFF) is consumed by the parser, so parseState starts at the destination key. However, its command metadata (Arity = -4, key-spec indices 2/3) describes the flat form where the operation token is still present, and NormalizeForACLs maps BITOP_* to the parent BITOP (whose IsSubCommand is false). The transaction path never accounted for the consumed token, causing two failures:

• BITOP NOT → EXECABORT: the queue-time arity check in NetworkSKIP computed a minimum of 3 args instead of 2, wrongly rejecting the valid BITOP NOT dst src (2 args).
• BITOP AND (binary ops) → transactional-lock assert: LockKeys resolved key-spec indices without the subcommand offset, so the destination key was never XLocked (Attempting to use a non-XLocked key in a Transactional context).

Fix

Apply the same BITOP special-case already used by cluster slot verification (RespServerSessionSlotVerify.cs) to the transaction path:

• TxnRespCommands.NetworkSKIP: treat cmd == RespCommand.BITOP as a subcommand when computing arity, and pass the flag through to key locking.
• TxnKeyManager.LockKeys: accept an explicit isSubCommand and forward it to TryGetKeySearchArgsFromSimpleKeySpec, which already applies the correct -2 key-index offset.

Tests

Added the two repro tests from the issue (BitopNotTransactionAsync, BitopAndTransactionAsync) to GarnetBitmapTests. Both fail without the fix and pass with it.

[Copilot]

Pull request overview

This PR fixes BITOP failures when executed inside MULTI/EXEC by aligning the transaction validation + key-locking logic with the fact that BITOP consumes its operation token (AND/OR/XOR/NOT/DIFF) during parsing (similar to the existing cluster slot verification handling). It also adds regression tests for the two reported transactional failure modes.

Changes:

• Treat normalized BITOP as “subcommand-like” during transaction queue-time arity validation (NetworkSKIP).
• Thread an explicit isSubCommand flag into transaction key locking so key-spec indices are resolved with the correct offset for BITOP.
• Add two regression tests covering BITOP NOT and BITOP AND inside a transaction.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
test/standalone/Garnet.test.complexstring/GarnetBitmapTests.cs	Adds regression tests for BITOP behavior inside MULTI/EXEC.
libs/server/Transaction/TxnRespCommands.cs	Adjusts transaction queue-time arity validation and passes subcommand-offset intent to key locking for BITOP.
libs/server/Transaction/TxnKeyManager.cs	Updates key-locking API to accept an explicit “resolve as subcommand” flag and forwards it to key-spec resolution.