AI assistant: let the server gather the context instead of the browser

Why

Today, when someone talks to the AI assistant, it's the browser that gathers everything the AI needs to know — the workflow, the job code, the logs — and sends it along with the message. The server just passes it on. The odd thing is that the server already has all of this information; we just never ask it to use it.

sequenceDiagram
    participant U as User
    participant B as Browser
    participant L as Lightning
    participant A as Apollo (AI)
    U->>B: types a message
    B->>B: gathers workflow, code, logs...<br/>(can fail silently)
    B->>L: message + context<br/>(one route for the first message,<br/>another for every message after)
    L->>A: forwards whatever arrived
    Note over L,A: if the context is missing,<br/>nobody notices

I think this one decision has quietly created most of the AI assistant bugs we've been chasing lately:

• The workflow travels one way on the first message and another way on every message after that. That's why some bugs only ever happen on the first message — it's what bit us in #5001, and what #4888 fixed before it.
• When the browser fails to send something, nothing tells us. The AI just answers without context, and no log explains why. #5001 took six weeks to diagnose mostly because of this silence.
• The same message field means different things depending on who sent it and from where, and knowing which kind of chat a session is relies on a handful of scattered hints rather than one clear answer.
• Every new feature adds one more thing the browser has to remember to send, and one more way for it to fail quietly. We've paid this tax on almost every AI PR this quarter (#4969, #5038).

What

I'd like us to flip the responsibility. The browser sends only what the user actually said, plus their choices (like "attach my logs"). When the server processes the message, it gathers the context itself, from what it already knows — the saved workflow, and the live editing session when there are unsaved changes.

sequenceDiagram
    participant U as User
    participant B as Browser
    participant L as Lightning
    participant A as Apollo (AI)
    U->>B: types a message
    B->>L: just the message + the user's choices
    L->>L: gathers the context itself<br/>(saved workflow, live editing session)
    L->>A: message + context
    Note over L: can't find something?<br/>one clear log line says what and why

What we'd gain:

• The first message and every later message would take the same path, so the whole family of "only on the first message" bugs disappears rather than getting fixed one at a time.
• Failures become loud: the server either finds the context or tells us exactly what it couldn't find.
• The browser gets simpler — it stops carrying data it was never a reliable courier for.
• One clear agreement with Apollo about what gets sent, instead of a shape both sides maintain by habit.

Design decisions

1. The context gathering should live where messages are processed, not where they arrive — so retries and background jobs get the same treatment as fresh messages.
2. Unsaved edits are the delicate part. The browser today sends what the user sees on screen, including changes they haven't saved. For the server to do the same, it has to read the live editing session, which touches the collaboration machinery — this was the part of #5038 we weren't sure about, and it deserves its own conversation, including what happens when the app runs on several nodes.
3. Nothing changes for Apollo at first: same information, just assembled in a more reliable place. The refactors brewing on the Apollo side (OpenFn/apollo#483 and the performance work in OpenFn/apollo#504) should aim at the same seam, but neither blocks the other.
4. We'd migrate one chat at a time, starting with the global chat — it's the newest and smallest surface, and the server-side YAML work from #5038 (closed unmerged, deliberately — the branch is the starting material for this) gives us a head start, including a set of hostile-input tests for the YAML generation.

One more thing this design quietly fixes: today, a user on a slow connection who sends their first message quickly can lose their workflow context, because the browser sends whatever it had loaded at that moment. We decided not to patch that case separately — it's rare, and this proposal makes it impossible rather than less likely.

Implementation outline

1. Grow #5038's fallback into the context gatherer for global chat, and let the browser stop sending the workflow along with global messages.
2. Do the same for job chat, retiring the "attach code" plumbing.
3. Then workflow chat, and delete the browser-side serialization once nothing uses it.
4. Along the way, collapse the duplicated option-handling on the server into one place.

Acceptance criteria

1. The first message and a later message in the same chat give the AI the same context, given the same workflow state.
2. Sending a message before the editor has finished loading, or on a brand-new empty workflow, still gives the AI its context — and a log line says where it came from.
3. The browser no longer sends serialized workflow or job code with any chat message.
4. Whenever context can't be gathered, exactly one log line says which chat, which message, and what was missing.

Estimate

Start with the server-side YAML work from #5038 and its hostile-input tests, then trace global chat message processing before extending the approach to job and workflow chat. Compare first and later messages, and verify the acceptance criteria: server-side context gathering, no browser serialization, consistent context, and one diagnostic log line when context is missing.