translator: an onCancelled lifecycle callback

Read against **0.10.1**.

## Problem

There is no `onCancelled` callback. The lifecycle set is `onQueued` / `onCompleted` / `onFailed`, and
`withQueuedNotification` decorates `enqueue` only — so a cancelled job simply stops existing and the
host is never told.

Two paths hit this:

1. **Explicit cancellation.** `POST /translate/cancel {ids}` → `TaskRunner.cancel(taskIds)`, which under
the payload-jobs runner calls `payload.jobs.cancel(...)` and then hard-`payload.delete`s the job
rows. A pending job vanishes silently.
2. **The plugin's own supersede path.** `enqueue` already supersedes per (document, target locale),
cancelling and deleting the prior job. So the plugin cancels jobs on its own initiative and tells
nobody.

`Task.cancelled` does not help: it derives from `error.cancelled` on the job row, and the plugin
deletes the row it just cancelled.

## Why this matters

A host tracking per-document translation state has to model "this run is no longer happening". With no
callback, it has to infer that — we release our own state first and treat the plugin call as
best-effort, which works but means the plugin and the host can disagree about what is in flight,
particularly on the supersede path where the host never asked for a cancellation at all.

## Suggested shape

`onCancelled(document, targetLocale, reason)` where `reason` distinguishes an explicit cancel from a
supersede. Firing it before the job row is deleted would let a host read the row if it needs to.

Start at the POST /translate/cancel path and TaskRunner.cancel, then trace payload.jobs.cancel, payload.delete, enqueue, and withQueuedNotification to understand both cancellation paths. Done means exposing onCancelled(document, targetLocale, reason) for explicit cancellation and superseding, firing it before the job row is deleted so hosts can track that the run has ended.

Written by the indexing model from the issue text.