### wai-quantum-qpu and wai-quantum-cli: a job on a provider outlives what sent it

A run on a person's provider waited in its process, and a job that had not finished in two hours was cancelled at the
provider, losing its place in the queue. If the process stopped first, the job went on and its id was gone, so its
counts could not be read. A device's queue can take days.

- **wai-quantum-qpu:** `job::start` writes a job down (`ledger`) before it is sent, and the provider's id as soon as it
  has one; nothing that cannot be recorded is sent. `job::check` and `job::follow` come back to it from any process, and
  seal its counts with what was true when it was sent: the program, the provider, the estimate. Running out of patience
  leaves the job where it is. `job::cancel` is someone asking. A request that did not complete may have reached the
  provider, so it is never sent again. `job::run` keeps no record, and still cancels what its bound outlasts.
- **wai-quantum-cli:** `run --provider` records the job and says its handle, and `--no-wait` answers with it at once.
  `providers jobs`, `providers collect` and `providers cancel` are new: `collect` exits 0 done, 1 ended otherwise, 2 still
  at the provider, and 75 when it could not ask, which says nothing of the job. A run that outlasts its two hours now
  exits 2, with the job left at the provider, where it was cancelled before. `run_on_provider` answers within a call
  with the job running and its id, and `get_provider_job`, `cancel_provider_job` and `list_provider_jobs` are new tools.
- **`wai.quantum.provider/1`:** §5.7 says what a job outlasting its client asks of a provider and a client. Nothing on
  the wire changes.

