GeezerVison

Fixes #2960

When a read fails or times out partway through a reply, phpredis throws but leaves the socket open. The rest of the reply arrives later, and the next command reads it as its own reply, so the connection stays out of step. This PR disconnects wherever phpredis gives up before the end of a reply, the same way redis_sock_gets() already does:

• a short read in redis_sock_read_bulk_reply() and redis_sock_read_bulk_zstr()
• a timeout before the reply type byte in redis_read_reply_type()
• an unknown reply type byte in redis_sock_read() and redis_sock_read_zstr()
• any failed read in cluster_check_response(), which now also rejects unknown reply type bytes
• a mismatched reply in cluster_send_direct(), and a mismatched reply with an unread payload in cluster_send_slot()

Testing

• The repro from Socket stays open after a read timeout in the middle of a reply, so every later command reads an earlier command's reply #2960 (Valkey 9.0 behind Toxiproxy), for Redis and RedisCluster, with binary and CRLF-text values: after the change, the command after the timeout reconnects and gets its own reply.
• Two more delayed-reply cases that this fixes: a node-directed RedisCluster::echo(), and Redis::rawCommand() with a timeout before the type byte.
• The same cases with TLS, persistent connections, and the igbinary serializer.
• tests/TestRedis.php --class Redis and --class RedisCluster (6-node cluster with the phpredis ACL user, as in CI) give the same results with and without the change. The only failures are session tests, testFailedTransactions, and testQueuedReplyModes, which fail in my local environment on develop too.

There is no new unit test, because the bug needs a server that stops partway through a reply. I can add one if you have a preferred way to do that in the test suite.