True cancellation and interruption semantics for embedded / long-running runs

[axel-havard]

Summary

For embedded use in larger systems, soft-cancellation is not enough. The host should be able to cancel a running predict-rlm job and have the runtime stop cleanly.

Problem

A host system can always ignore the eventual result, but that does not:

• stop model inference already in progress
• stop future recursive expansion
• stop pending capability calls
• reclaim compute quickly
• prevent unnecessary side effects

For practical operations, the runtime needs an explicit cancellation model.

Proposed direction

Support cancellation/interruption with clear semantics:

• host can request cancellation
• runtime stops future recursive work
• pending safe boundaries are honored cleanly
• terminal result is cancelled, not generic failure
• capability/tool calls should see cancellation where possible

Why this matters

Needed for:

• budget control
• responsive UI
• approval workflows
• user-initiated stop actions
• preventing waste on obviously bad branches

Acceptance criteria

• host can request cancellation programmatically
• runtime surfaces cancelled as a distinct terminal state
• cancellation appears in event stream and structured trace
• behavior is documented for in-flight capability calls