Handling failures mid-stream

Because the response is a long-lived stream, errors can happen after you've started sending. Design for it:

• Wrap the orchestration so that on error you can still write an error event and the done sentinel, rather than dropping the connection silently. The client should show a clear failure, not hang.
• Persist what you can. If the user's message was saved before the stream started (it should be, Chapter 9), a failed turn doesn't lose their input.
• Consider resumability for long tasks: if each unit of work is persisted as it completes (e.g. each extracted cell), a dropped connection doesn't lose finished work, and a retry can resume.