Idempotency: honor Idempotency-Key header and apply it to deletes

[sklinkert]

Context

The recently added race-safe idempotency layer (#86) is well-built and correctly placed at the application-service layer, but it had two gaps at the HTTP boundary:

1. Deletes bypassed idempotency entirely — DeleteProductController/DeleteSellerController built their commands with only Id and never set IdempotencyKey, even though the command structs already had the field. An empty key short-circuits withIdempotency, so delete replays were never cached.
2. The key travelled only in the JSON body (idempotency_key) rather than the conventional Idempotency-Key HTTP header — a notable smell for a reference repo people copy into production.

This PR closes both gaps. No new infrastructure — the existing withIdempotency wrapper, repository, table, and command fields are reused as-is.

Changes

• New idempotencyKey helper (internal/interface/api/rest/idempotency.go) — prefers the Idempotency-Key header, falls back to the request body's idempotency_key field for backward compatibility (header wins when both are present).
• All six mutating handlers (product/seller create, update, delete) now resolve the key via the helper. Deletes now carry a key into DeleteProductCommand/DeleteSellerCommand.
• Unit tests for the helper (header precedence / body fallback / empty).
• OpenAPI spec — reusable Idempotency-Key header parameter referenced from every write operation, plus an updated description.
• README — documents that the header is preferred and that deletes are idempotent too.