core: cancellation in push mode

Cancellation works today because the scheduler holds a connection to the process running the
job. It can tell the executor to stop, and the executor can act on it.

The naive push design loses that. Once the scheduler has POSTed to a URL, there is no channel
back to the running work. cancel() marks a row and the target keeps going — the job is
"cancelled" in the database and still burning platform time and still going to write its result.
That is worse than not supporting cancel, because the API says it worked.

Cancel is a headline differentiator. Design it in before push ships, not after.

Options to weigh in the issue:

• A cancellation endpoint on the target. The scheduler calls a second URL. Requires the
  target to route it to the running invocation, which most serverless platforms make hard.
• Poll on the settle path. The target asks "is this still mine?" when it extends its lease
  or reports progress, and stops when the answer is no. Cooperative, cheap, and only as prompt
  as the heartbeat interval — but it composes with #845.
• Fence at settle. Cancelled work runs to completion and its result is rejected. Correct,
  costs the platform time, and is the floor rather than the answer.

Whatever is chosen, the semantics must be written down per topology. "Cancel stops the work"
under attach and "cancel prevents the result from landing" under push are different promises,
and a user who moves from one to the other must be told which they now have.

Start by comparing the three cancellation options in this issue and read the related #845 discussion for how polling could compose with push mode. Done means choosing and documenting cancellation semantics for attach and push topologies, including whether work stops or only its result is fenced.