Expected Behavior

VectorScoreSliceCmd (used by VSimWithScores, VSimWithArgsWithScores, VLinksWithScores) should correctly parse replies from both RESP2 and RESP3 connections.

Current Behavior

VectorScoreSliceCmd.readReply calls rd.ReadMapLen() directly without first checking the reply type via PeekReplyType(). This means it only works with RESP3 (map) responses and will fail on RESP2 connections, which return flat arrays.

Possible Solution

Update VectorScoreSliceCmd.readReply to peek the reply type and handle both RESP2 (flat array of [name, score, name, score, ...]) and RESP3 (map of name -> score) formats, similar to how the new VectorAttribSliceCmd and VectorScoreAttribSliceCmd in #3753 already handle both protocols.

Steps to Reproduce

1. Connect to Redis 8.x using RESP2 (default protocol)
2. Create a vector set and add elements
3. Call VSimWithScores or VLinksWithScores
4. Observe a parse error from ReadMapLen failing on an array reply

Context (Environment)

Any RESP2 connection to Redis 8.x+ with vector set commands.

Detailed Description

The VectorScoreSliceCmd.readReply in command.go assumes the reply is always a RESP3 map. On RESP2 connections, Redis returns a flat array ([name1, score1, name2, score2, ...]), which causes ReadMapLen to fail. This affects all commands returning *VectorScoreSliceCmd: VSimWithScores, VSimWithArgsWithScores, and VLinksWithScores.

Possible Implementation

Add a PeekReplyType() check at the top of readReply. If the type is proto.RespMap, use the current map-based parsing. If it's an array, read the array length, verify it's a multiple of 2, and parse [name, score] pairs sequentially.