v0.24.4

A patch release: a run stopped during a tool reads back as stopped, not failed.

Fixed

A run stopped while a tool is running records its last answer as aborted (#713, closes #712). Before this fix, the live stream settled such a run aborted, but entries() read its last answer as outcome: { status: "failed", error: { message: "This operation was aborted" } }. A client reading the run back (after a reload or restart) then showed a failure with a Retry, which would run the stopped tool again. The answer now reads outcome: { status: "aborted" }, the same as its live message_finished and the run's run_settled. The stopped call's own tool entry is still isError: true, since that call did not complete.

The rule is that an answer that failed while its run's stop was in effect is recorded as aborted, wherever the stop landed. A failure recorded before the stop stays failed. For example, a provider error whose retry was then stopped during its backoff failed on its own. docs/design/session-control.md documents this.

The cause is in pi 0.99.2. After a tool is aborted, the agent loop asks the model once more. The request-setup step throws the abort, and pi records that as stopReason: "error" whatever the abort signal says. FastAgent corrects the message before pi writes it to the record. If pi fixes this upstream, the correction does nothing.

Full Changelog: v0.24.3...v0.24.4