Problem

When a user sends "stop" to abort an in-progress generation, the abort signal cancels the AI run. However, the abort is handled entirely in-memory — there is no persistent record that the turn was aborted. If the gateway crashes after an abort but before cleanup completes, a recovery mechanism could re-deliver the partial reply since it has no way to know the turn was intentionally aborted.

Steps to reproduce

1. Send a message that triggers a long AI generation
2. Send "stop" to abort
3. Kill the gateway before the abort fully completes
4. Restart the gateway

Current behavior

The abort cancels the in-memory AI run, but:

• No persistent state records that this turn was aborted
• The delivery queue may still contain the partially-generated reply
• On restart, recovery logic sees a pending delivery and re-delivers it
• The user receives a partial reply they already aborted

Expected behavior

Abort should be recorded persistently so that recovery mechanisms know not to re-deliver aborted turns. A turn marked as "aborted" in a durable store should be skipped by recovery on restart.