Redis-backed idempotency store falsely conflicts every retried request

This breaks the Redis backend's core promise -- the exact thing pkg/idempotency's README section on concurrency correctness spends the most words defending -- for every single request, not just an edge case. Any deployment running STORE_BACKEND=redis (the recommended, multi-replica-safe production configuration) would see every retried request rejected with 409 idempotency_key_reused, even though the retry is byte-for-byte identical to the original. A client that retries after a timeout (the single most common reason a client resends a request with the same Idempotency-Key) gets a hard, unrecoverable conflict instead of the replayed response it's supposed to get -- indistinguishable, from the client's point of view, from a real bug in their own request construction, which is exactly the kind of misleading error that burns hours of the wrong team's time during an incident.

RedisStore.Begin calls a Lua script (begin.lua) that expects its arguments in a specific order: ARGV[1] = fingerprint, ARGV[2] = ttl_ms, ARGV[3] = created_at. The Go call site passes them in a different order.

store := idempotency.NewRedisStore(client, time.Second) store.Begin(ctx, "k", "same-fingerprint", time.Minute) store.Complete(ctx, "k", idempotency.StoredResponse{StatusCode: 200}) time.Sleep(2 * time.Millisecond) // ensure a different wall-clock timestamp claim, _ := store.Begin(ctx, "k", "same-fingerprint", time.Minute) fmt.Println(claim.Status) // got: Conflict, want: Replay

This is a genuine cross-component protocol mismatch: begin.lua and its Go caller each independently encode an assumption about what each positional ARGV slot means, and nothing in the type system (Lua has no static types, and redis.Script.Run takes a bare ...interface{}) can catch the two sides drifting apart. No Redis-level error is raised either -- both a timestamp string and a fingerprint hash are just opaque strings to Redis and to Lua, so the corruption is entirely silent until you notice the behavioral symptom (spurious conflicts), which is exactly what makes this the hardest bug in this task list to track down from symptoms alone.

Read pkg/idempotency/lua/begin.lua's comment block at the top -- it documents exactly which ARGV index means what. Then look at the actual argument list in the beginScript.Run(...) call inside RedisStore.Begin (pkg/idempotency/redis.go) and check whether the order of the three trailing arguments actually matches that documented contract.