Add idempotency keys for mutating ML-API endpoints

[pavsoss]

Summary

Mutating endpoints could not be retried safely. /feedback appends a row to a
CSV on every call, /scan-emails re-runs an upstream fetch plus a model scan,
and /reload-model hot-swaps the serving model set — so any client or proxy
retry silently performed the side effect twice.

This adds opt-in idempotency via an Idempotency-Key request header:

• First request with a key runs the handler and caches its status + body.
• Same key, same request replays the cached response without re-running the
  handler or its side effects.
• Same key, different payload returns a typed IDEMPOTENCY_CONFLICT (409),
  surfacing the client bug instead of serving an unrelated cached response.
• No key preserves existing behaviour exactly — the layer is a pass-through.

The store is in-process and TTL-bounded (configurable via
IDEMPOTENCY_TTL_SECONDS), enough to absorb client-side retries without the
operational cost of a shared backing store. A per-key lock ensures two
simultaneous retries can't both execute the handler.

Applied to /feedback, /scan-emails, and /reload-model, composing beneath
the existing request-validation and rate-limit decorators.

Test plan

Regression coverage for the header-absent passthrough, the replay path
(asserting the side effect happens exactly once), the key/payload mismatch
conflict, and TTL-based expiry via an injected clock.

Closes #1022

[vercel]

@pavsoss is attempting to deploy a commit to the Aditya Sharma's projects Team on Vercel.

A member of the Team first needs to authorize it.