More robust AI assistant error handling

What this is

A few AI assistant failures don't fail well. They either hide the real cause or crash the channel outright, which is what made a recent P2 slow to diagnose. This groups the work to make assistant errors surface cleanly: a clear, serializable error to the user and a useful reason in the logs, never a silent no-op or a dead socket.

The specific bugs are tracked in the sub-issues below.

Worth doing while we're here

When the assistant attempts a code change and produces nothing, the user gets a message with nothing to apply and no hint why. The trigger can't just be "no code present" since plenty of replies legitimately have none (a plain "what does this adaptor do?" answer has no code and shouldn't warn). Apollo already knows when an edit was attempted but didn't apply (it returns a diff with patches_applied and an optional warning), so we can lean on that signal to show something like "I tried to update your code but couldn't apply the change."

Out of scope

The Apollo behaviour that returned no code for empty jobs is fixed separately in OpenFn/apollo#539 / OpenFn/apollo#540. This epic is about how Lightning handles and surfaces assistant errors.