### wai-quantum 0.8.1, wai-quantum-qpu 0.4.1 and wai-quantum-cli 0.2.4: an optimisation that stops and goes on, a job on a provider that outlives what sent it, and the job service's keys, reruns and tasks

This release carries the six entries on WAI Quantum's packages below it, from a job on a provider that outlives what
sent it down to an optimisation that stops and goes on; the other entries among them are not part of it, and the
desktop app's are its own 0.1.2. Each of the six only adds or fixes, so each package moves its last number
(`wai-quantum/VERSIONING.md`, "Before 1.0"): `wai-quantum-qpu` 0.4.1 requires `wai-quantum` 0.8.1, and
`wai-quantum-cli` 0.2.4 requires both; the job service is 0.2.2, and the Python package is 0.1.2, carrying the 0.8.1
engine. `@transaction-science/wai-quantum` stays 0.1.1, as nothing in it changed, and the desktop app stays 0.1.2.
Nothing is deprecated.

- **wai-quantum 0.8.1:** an optimisation goes on from a checkpoint to the same bytes
  (`engine::variational::optimize_resumable`, `call_optimize`, `wai.quantum.optimize-checkpoint/1`); the refusal code
  `J034`, for an idempotency key that does not read or that names another request; and `wai.quantum.job/1` lists the
  status `interrupted`, which the service has returned since its jobs were first kept across restarts, and gains the
  optional `interruptions`.
- **wai-quantum-qpu 0.4.1:** a job on a provider is written down before it is sent (`ledger`), and `job::start`,
  `job::check`, `job::follow` and `job::cancel` come back to it from any process. It requires `wai-quantum` 0.8.1.
- **wai-quantum-cli 0.2.4:** `run --provider --no-wait`, `providers jobs | collect | cancel`, and
  `optimize --checkpoint | --slice`; `submit` and `task` send each job under a key of their own. The local MCP server
  gains `get_provider_job`, `cancel_provider_job` and `list_provider_jobs`, and runs `run_on_provider` as a task.
- **The job service 0.2.2:** `POST /v1/jobs` and `POST /v1/run` take an `Idempotency-Key`, and its MCP server's three
  runs an `idempotency_key`; a job it was running when it stopped runs once more (`rerun` in `GET /v1`'s `restored`);
  and those three runs are MCP tasks.
- **The Python package 0.1.2:** `Service.submit` and `Service.run` take `idempotency_key`, and a job the service
  interrupted ends the wait. Its name is unchanged.
- **What moves with the version:** the engine's version is among the sealed bytes of a stamped result, so the
  page's pinned digests move (the course check's 1a9aa0ad… to 49a9fdb8…, the compile's beffb3cb… to 198ea9bd…,
  the estimate's db90b147… to acbd7208…), the answer set's stored seal is written again
  (`WAI_ANSWER_BUNDLE_WRITE=1`), and the notebooks' stored outputs are stored again. The job pins strip the engine and
  schema, and do not move.
- **What a caller may have to change:** nothing.
- Every lockfile that holds one of these crates moves with them (seventeen), so a `--locked` build still reads its
  own, and `wai-rs`'s optional requirement on the engine moves to 0.8.1. The views page's manifest records the new
  digest of `wai-quantum-views`'s lockfile.
- **Breaking:** `wire:corpus:wai/quantum-conformance/answers/cases/bell-stored.wqa`: the stored answer's receipt
  marker seals the engine's version, so it is written again at 0.8.1, as at each release. A conformance run checks a
  stored answer with the engine that wrote it: 0.8.0's corpus with 0.8.0, this one with 0.8.1.
- **Breaking:** `wire:corpus:wai/quantum-conformance/answers/cases/bell-stored-changed.wqa`: the same stored answer
  with one sample's shots changed, written again with it; it still does not verify.
- **Breaking:** `wire:corpus:wai/quantum-conformance/answers/bundle.json`: the corpus inline, written again with both
  stored answers.

