fix(idempotency): in-flight reservation closes concurrent double-create race (bug-bash #21)

[mastermanas805]

What

The idempotency middleware did GET(miss) → run handler → SET, with no atomic reservation between the GET and the SET. Two requests carrying the same Idempotency-Key (or the same body-fingerprint) racing in that window both observed redis.Nil and both ran the handler — double-creating real backend resources on the authenticated /db,/cache,/nosql provision paths, which have no other per-burst dedup gate.

(The deploy path is already race-safe via CreateDeploymentWithCap's SELECT … FOR UPDATE; this race is the db/cache/mongo resource-waste case.)

Fix

On a cache miss, write an in-flight reservation marker via SETNX (idemEntry.InFlight, 60s TTL) the instant the handler starts. A concurrent same-key request reads the marker in the top GET hit-block and returns 409 idempotency_key_in_progress (retryable — same envelope as the existing conflict 409) instead of re-running the handler.

• Real response overwrites the marker on completion (plain SET).
• Non-cacheable paths (5xx, handler error, mutable 4xx) DELETE the marker so an immediate legitimate retry isn't blocked.
• Applied symmetrically to both the explicit-key and fingerprint branches.
• SETNX is best-effort / fail-open — a Redis hiccup never blocks provisioning (documented dedup posture: best-effort, never a correctness gate).

Coverage

Symptom:        concurrent same-key requests both run handler → double provision
Enumeration:    GET→Next→SET in idempotencyExplicit + idempotencyFingerprint (2 sites)
Sites found:    2
Sites touched:  2
Coverage test:  TestIdempotency_{ExplicitKey,Fingerprint}_ConcurrentInFlight_Returns409
Live verified:  pass under -race; new funcs + all 6 Del lines 100% covered

Both tests hold request A inside the handler (blocked on a channel) so B is guaranteed to observe A's live reservation → 409, handler runs exactly once.

🤖 Generated with Claude Code