### The job service: a job sent again under its key is the same job

A client that lost an answer could not safely ask again: a second submission was a second job, counted against its
limits. The three MCP tools that run also declared `idempotentHint: true`, which was not so.

- **wai-quantum-service:**
  - `POST /v1/jobs` and `POST /v1/run` take an `Idempotency-Key`, and `run_quantum_circuit`, `run_quantum_set` and
    `run_on_target` take `idempotency_key`. Sent again with the same key and request, a job is answered with the
    key's job, before any limit and counting as no submission. With another request, the key is refused (`J034`).
  - A key names its job while the job is kept, whatever its status, but for a job the service interrupted: that key
    runs the request again. A record keeps the key's digest with the client's name, never the key, and the key names
    its job after a restart.
  - The three tools' `idempotentHint` is now false: without a key, each call is a new job.
  - `GET /v1` states `idempotency`, and the OpenAPI document describes the header.
- **wai-quantum:** the refusal code `J034`.
- **wai-quantum-cli:** `submit` and `task` send each job under a key of their own. Where no answer came back, they
  send it again under that key, twice at most, if the service says it keeps keys.
- **wai-quantum for Python:** `Service.submit` and `Service.run` do the same, and take `idempotency_key`. A job the
  service interrupted now ends the wait; before, the wait went on to its deadline.

