✅ test(e2e/redis): exercise read-from-replica path

The redis scenario only set redisCacheHost, so it validated the writer
but never the round-robin reader path this feature adds. Split the mock
into two roles: the primary (--redis-addr) now answers every GET with a
miss, while the replica (--redis-read-addr) serves the hardcoded
verdicts. The scenario points redisCacheReadHosts at the replica (twice,
to drive round-robin), so the banned-IP-blocked assertion only passes if
the plugin actually reads decisions from the replica rather than the
primary.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

tests/e2e/mock/scenarios/redis/run.sh

@@ -7,10 +7,13 @@ source "$HERE/../../lib/common.sh"
 
 SCENARIO=redis
 
-# Redis cache check: the mock returns "f" (not banned) for 1.2.3.4 and "t"
-# (banned) for 1.2.3.5. All other IPs return a miss, which falls through to the
-# LAPI (no decision → allowed). This proves the plugin reads cached decisions
-# from Redis correctly.
+# Redis cache check: reads are offloaded to a replica (redisCacheReadHosts)
+# while writes go to the primary (redisCacheHost). The replica mock returns "f"
+# (not banned) for 1.2.3.4 and "t" (banned) for 1.2.3.5; the primary mock always
+# misses. All other IPs miss on the replica and fall through to the LAPI (no
+# decision → allowed). Because the verdicts live only on the replica, the banned
+# IP being blocked proves the plugin reads decisions from the replica, not the
+# primary.
 body() {
   echo "[$SCENARIO] cached clean IP must pass"
   assert_status "http://127.0.0.1:${WEB_PORT}/foo" 200 -H "X-Forwarded-For: 1.2.3.4"