fix(resp,limits): reject nested arrays, store-down latch, clamp dial to call budget

Reject a nested array reply instead of recursing into it. decodeReply
now takes a depth parameter; a '*' type byte is accepted only at
depth 0, so an element that is itself an array (decodeArray calls
decodeReply at depth+1) is a protocol error rather than a recursive
call. A crafted "*1\r\n*1\r\n..." stream repeated could otherwise
recurse to Go's stack limit — a fatal, unrecoverable error, not a
panic recoverPanic can catch — from only a few megabytes of wire
input. Also lower respMaxArrayLen from 1<<20 to 1024: none of this
client's commands (AUTH, SELECT, INCRBY, EXPIRE, GET) ever return an
array reply at all, so even 1024 is generous headroom, not a limit
tuned to real traffic.

Add a store-down latch to the limiter (limits.go): after any store
operation fails, record the failure time; for storeDownLatchFor (5s)
afterward, every storeIncrBy/storeGet call short-circuits straight to
the fail-open/fail-closed policy without attempting the store at all.
One request can touch several counters (its own and its group's,
request/token/cost, day/month) — each respClient call is already
bounded to ~respCallTimeout on its own, but without the latch every
one of those still paid a fresh bounded wait against a store that had
just proven unreachable. After the window, the next operation probes
the real store again: a natural half-open retry, no separate recovery
state. Guarded by the same logMu mutex lastLogAt already uses for this
kind of small timestamp state.

Clamp respClient's dial timeout to the remaining call budget:
dialTimeoutFor returns min(respDialTimeout, time.Until(deadline)),
with a respDeadlineExceededErr (implements net.Error, Timeout() true)
returned outright if the deadline has already elapsed — e.g. this
call queued behind the client's mutex for its whole budget while an
earlier call was stuck. Without this, a future increase to
respDialTimeout alone, leaving respCallTimeout untouched, could
silently let one dial attempt consume more of a call's total budget
than the call-level deadline is supposed to allow.

New tests: a nested-array reply and an array length one over the new
1024 cap, both asserted as protocol errors; a countingErrorStore stub
proving a second checkAndCount within the latch window makes zero
additional store calls, and that the store is probed again once the
window elapses. Tightened TestLimiter_FailOpenTrue_
HungRedisServer_FallsBackQuickly's bound from <6s to <3s now that the
latch collapses its two store ops into one real network attempt.

redis_store_test.go

@@ -138,14 +138,17 @@ func TestLimiter_FailOpenTrue_DeadRedisAddress_FallsBackAndAllows(t *testing.T)
 }
 
 // TestLimiter_FailOpenTrue_HungRedisServer_FallsBackQuickly is review item
-// 1's limiter-level proof: a hung (accepts the connection, never replies)
-// Redis-compatible server must not make a failOpen=true request wait out
-// several stacked multi-second timeouts (the pre-fix behavior for a
-// checkAndCount call that performs several store operations) — each of
-// checkAndCount's two store ops here (req:min, req:day) is bounded by one
-// respCallTimeout, not respCallTimeout times every read/write step it
-// happens to perform, so the whole call stays well under the old
-// multi-times-respCallTimeout stall.
+// 1's limiter-level proof (round 1), tightened by the round-3 store-down
+// latch: a hung (accepts the connection, never replies) Redis-compatible
+// server must not make a failOpen=true request wait out several stacked
+// multi-second timeouts (the pre-fix behavior for a checkAndCount call
+// that performs several store operations). checkAndCount's two store ops
+// here (req:min, req:day) would each independently be bounded by one
+// respCallTimeout — already a large improvement over the old
+// per-operation-multiplied stall — but the store-down latch (limits.go)
+// goes further: the first op's failure latches the store down, so the
+// second op skips the network call entirely and the whole call costs
+// only ~one respCallTimeout, not two.
 func TestLimiter_FailOpenTrue_HungRedisServer_FallsBackQuickly(t *testing.T) {
 	ln := newHungListener(t)
 	store := newRedisStore(newRESPClient(ln.Addr().String(), "", 0))
@@ -159,7 +162,7 @@ func TestLimiter_FailOpenTrue_HungRedisServer_FallsBackQuickly(t *testing.T) {
 	if v != nil {
 		t.Fatalf("want no violation with failOpen=true and a hung store, got %+v", v)
 	}
-	if elapsed >= 6*time.Second {
-		t.Fatalf("elapsed = %v, want well under the old worst case (two bounded store ops, not many stacked timeouts)", elapsed)
+	if elapsed >= 3*time.Second {
+		t.Fatalf("elapsed = %v, want < 3s (one respCallTimeout for the first op, the second latched and skipping the network entirely)", elapsed)
 	}
 }