idempotency_key is accepted on POST /jobs but silently ignored

JobCreateRequest already accepts an idempotency_key field, and Settings.idempotency_ttl_seconds already exists as a config knob for how long a key should be remembered -- but nothing reads either of them. Two POST /jobs calls with the same idempotency_key today create two entirely independent jobs. This is arguably worse than the field not existing at all: a client that reads the field's presence in the API schema and builds retry logic around it gets silent data duplication instead of a clear "not supported" error.

Two POST /jobs calls carrying the identical idempotency_key create two independent jobs with different ids, instead of the second call returning the original job's id.

1. pytest practice_tickets/tests/test_ticket_08_idempotency_key_ignored.py -v
2. Observe: two POST /jobs calls with the same idempotency_key (e.g. "checkout-order-9001") return two different job_ids.

The textbook use case: a client's POST /jobs call times out from its own side (network blip, client-side timeout) before it ever sees the response, even though the server successfully created the job. Without idempotency, the client's only safe options are "assume it failed and resubmit" (risking a duplicate, possibly-expensive job) or "assume it succeeded and do nothing" (risking silently losing a job that never actually started). An idempotency key turns "resubmit if unsure" into the actually-safe default.

The natural place to remember "this key maps to this job_id, for this long" is Redis, alongside the job document itself (app/store.py already owns that connection and TTL patterns) -- a small idempotency:{key} -> job_id mapping with its own TTL is the same shape as everything else this module already does. create_job() is where that lookup (and, on a miss, the write) needs to happen, before a new job is actually created.