Implement idempotency key pattern (Redis + persistent table)

[tayebmokni]

Summary

Implement the idempotency pattern from §7: every mutating task payload carries an optional idem_key; the handler's first action is idemStore.Claim(ctx, taskType, idemKey, ttl) — Redis SET NX EX. Persistent idempotency for "must not fire twice ever" tasks (e.g., webhook delivery) uses the task_idempotency table written inside the same DB transaction as the side effect.

Design reference

• docs/12-jobs-cron.md §7 (Idempotency)

Acceptance criteria

• internal/jobs/idem/idem.go exposes idemStore.Claim(ctx, taskType, key, ttl) (bool, error) (Redis SET NX EX)
• Key format: idem:{task_type}:{idem_key}; value: worker_id + completed_at for debuggability
• Migration creates task_idempotency(task_type TEXT, idem_key TEXT, completed_at TIMESTAMPTZ, result_hash TEXT, PRIMARY KEY (task_type, idem_key))
• idemStore.ClaimPersistent(ctx, tx, taskType, key) writes to the table inside the caller's TX
• Handlers use the Redis layer for cheap-redo tasks (cache/revalidate/reindex); persistent layer for webhooks/emails to external recipients
• §7.2 per-task formulas wired: email.send → sha256(template+":"+to+":"+content_hash) TTL 24h; webhook.deliver → (subscription_id, event_id) TTL 7d; etc.
• Metric gonext_jobs_idempotency_skips_total{task_type} increments on claimed-already
• Unit tests for both Redis and persistent layers, including TX-failure-rollback

Dependencies

#258

Complexity

M