Cancel Backtest

Cancel a backtest (Q-1220, consume-at-scale O.21 / doc 10 §3).

The durable request is a status, and which status depends on who holds the run:

• QUEUED -- no worker holds it. The row goes straight to CANCELLED here, with every cancellation stamp; the SQS message still arrives at a worker, whose atomic claim (WHERE status = 'QUEUED') refuses it -- that refusal IS the "re-check at claim". The compute-seconds spend entry is zeroed (nothing ran); the run unit stays consumed (a cancellation is the user's act -- the worker's cancelled arm makes the same choice, and the founder ruling on it is doc 30 §4's).
• RUNNING -- a worker is executing. The row becomes CANCEL_REQUESTED and the worker honours it at its next phase boundary (backtest-worker/src/cancellation.py): the response says cancel_requested, the client polls, and the row reaches CANCELLED within one phase -- or completes anyway if the request landed after the worker's last checkpoint (cancel_requested_at is kept as the evidence either way).
• CANCEL_REQUESTED -- already asked. Idempotent: the current row.
• anything else -- terminal. 409 BACKTEST_ALREADY_TERMINAL.

Every write is guarded on the status it read, so a race with the worker (a claim landing between the read and the QUEUED write, a completion landing before the RUNNING write) re-reads and falls through to the truthful branch instead of overwriting a terminal row.