fix(resp): bound store-call latency, cap wire lengths, cover fail-closed budget path

Bound respClient's worst-case latency to one respCallTimeout per
do/pipeline call instead of per read/write/handshake step. Compute a
single absolute deadline at call entry, apply it once via
conn.SetDeadline after connecting (covering the AUTH/SELECT handshake
and the call's own command I/O), and skip the reconnect-retry when the
failing attempt was a timeout (errors.As -> net.Error, Timeout()) — a
peer that accepted the connection and went silent must not be asked
the same non-question twice. Previously each read, write, and dial got
its own fresh 2s budget and every caller queued behind the client's
single mutex, so a hung (not merely refused) Redis-compatible server
could stall one checkAndCount call for 16-32s+.

Cap decodeBulk/decodeArray's wire-declared lengths (respMaxBulkLen
64MiB, respMaxArrayLen 1<<20) before allocating: an unguarded
"$9223372036854775807\r\n" overflows n+2 into a negative slice length
and panics make([]byte, n+2); a merely huge-but-valid length forces an
outsized allocation either way. decodeBulk also now verifies its two
trailing bytes are CRLF. Bound readLine to respMaxLineLen (64KiB),
reading byte-by-byte so it can bail before ever buffering an unbounded
line from a peer that never sends '\n'.

Fix TestLimiter_FailClosed_BudgetReadReturnsStoreDownViolation: the
erroringStore it used fails incrBy too, so checkAndCount's own
increment loop already returned a storeDown violation before
evaluateScope (and therefore budgetViolation) ever ran, leaving
budgetViolation's storeDown branch uncovered. Replace it with a stub
that only fails get, so the test's TokensPerDay limit actually drives
evaluateScope into budgetViolation's fail-closed path.

Document redis_store.go's incrBy as deliberately at-least-once: the
reconnect-retry can re-send INCRBY after a lost reply (possible
over-count), and fail-open can additionally count in the fallback —
both fail-safe (more restrictive), never fail-open in the unsafe
direction.

Validate Redis.DB >= 0 in newConfiguredLimiter alongside Address, so a
negative db is a constructor error rather than a SELECT -1 on the wire.

New tests: a hung (accepts, never replies) fake RESP server proving a
respClient call and a failOpen limiter call both stay bounded rather
than stacking timeouts; decodeReply subtests for an oversized bulk
length, a length just over the cap, a huge array length, a bad bulk
trailer, and an oversized line; a negative-DB constructor-rejection
test.

redis_store.go

@@ -26,6 +26,18 @@ func newRedisStore(client *respClient) *redisStore {
 // the count. ttl is rounded up to whole seconds (Redis EXPIRE's unit),
 // with a floor of 1s so a sub-second ttl never turns into EXPIRE 0 (an
 // immediate delete).
+//
+// Semantics are deliberately at-least-once, not exactly-once, both in the
+// conservative direction (never under-counts): respClient.pipeline's
+// reconnect-once retry can re-send this same INCRBY if the first attempt's
+// reply was lost after the server already applied it (e.g. the connection
+// dropped between the server processing INCRBY and the client reading its
+// reply), which can over-count by n on that key; and the limiter's
+// failOpen path can additionally count the same request in its in-process
+// fallback store when a call to this method errors out after a partial
+// success upstream. Both are accepted trade-offs — a rate/budget counter
+// that occasionally over-counts by one request's worth is fail-safe (more
+// restrictive than reality), never fail-open in the unsafe direction.
 func (s *redisStore) incrBy(key string, n int64, ttl time.Duration) (int64, error) {
 	ttlSeconds := int64(ttl / time.Second)
 	if ttl%time.Second != 0 {