Envoy Redis proxy SCAN implementation not compatible with Redis specification

Title: Envoy Redis proxy SCAN implementation not compatible with Redis specification

Description: When using the SCAN command through Envoy's Redis proxy against a Redis cluster, Envoy fans out the SCAN request to all Redis masters and returns concatenated responses. According to the Redis specification, SCAN return value is an array of two values: the first value is the new cursor to use in the next call, the second value is an array of elements. However, Envoy returns multiple cursor/keys pairs (one per master).

Expected result:

1) "288"
2) 1) "test:key:895"
   2) "test:key:565"
   3) "test:key:963"
   4) "test:key:330"
   5) "test:key:457"

Actual result (when cluster has 3 masters):

1) "133"
2) 1) "test:key:248"
   2) "test:key:57"
   3) "test:key:116"
   4) "test:key:191"
   5) "test:key:514"
3) "277"
4) 1) "test:key:942"
   2) "test:key:982"
   3) "test:key:995"
   4) "test:key:567"
   5) "test:key:812"
5) "69"
6) 1) "test:key:859"
   2) "test:key:224"
   3) "test:key:543"
   4) "test:key:542"
   5) "test:key:621"

SCAN cursors are instance-specific, i.e., each cursor is only valid for the Redis instance that generated it. When Envoy fans out SCAN to all masters and returns multiple cursor/keys pairs, cursors from different masters are mixed, with no way to identify which cursor belongs to which master. This makes it impossible to reliably continue scanning, as there's no way to match cursors to their originating masters across requests. As a result, SCAN through Envoy's Redis proxy cannot reliably scan the keyspace, leading to unpredictable behavior, resource exhaustion, or incomplete scans.

Relevant Links:

• Redis SCAN command spec
• Envoy SCAN implementation PR