Global assistant: Forward attachments to Apollo

[hanna-paasivirta]

Description

Global chat ignored the "Send logs" and "Send scrubbed I/O" checkboxes. The UI said the data was attached; nothing was sent to Apollo. This wires it up.

Changes

• Global chat now sends an attachments list to Apollo: run logs, scrubbed step input, scrubbed step output
• Log lines carry job_id, step_id and level so Apollo can tell which job a line came from
• The selected run id now survives session creation, so the log attachment can be resolved on the first message as well as later ones
• If Apollo says the attachment is too large, the user gets a clear message naming the checkbox to untick, instead of raw Apollo text
• Logs are fetched project-scoped, matching how step I/O is already fetched

Not in scope

• No size limit in Lightning. We rely on Apollo rejecting oversized payloads and logging them in Sentry so we can assess how often this happens.
• Run-level dataclips are not sent. Job chat and workflow chat never sent them either, and this PR is about parity
• No role gating. The AI assistant has never distinguished viewer from editor (both :access_write and :access_read resolve to plain project membership), so global chat now matches job chat rather than changing that
• There are existing bugs in the job_chat log attachment, and this PR does not attempt to fix them. Some seem triggered by editing the workflow after running it. I did not notice these issues in this new global assistant attachment implementation.
• There is no option to attach logs from the canvas view. This should probably be made possible, but this will be handled in another issue: Global Assistant: How to allow users to attach full YAML, Logs and I/O Data #5037

Safety

• Job chat and workflow chat payloads are unchanged. Their existing payload tests pass without edits
• Only global_chat_stream was touched in the Apollo client
• The one shared change is the SSE error handler, which gained a branch for the new error type. All existing fallbacks are untouched, so nothing breaks if Apollo is still on main

Closes #5093

Validation steps

You can test with Apollo on main, although this could surface very occasional lost attachments when forwarding the query to a subagent (fixed onsubagent-context OpenFn/apollo#649)

1. Open the assistant in a workflow with past runs. Tick the boxes for Global assistant, and attach logs and I/O data and ask the assistant if it can see your logs and check it describes them correctly.
2. Repeat this from different steps with new conversations and conversations that continue across different views.
3. Make edits to the workflow and come back to the assistant to verify it can still see logs. In the job_chat implementation, there seem to be bugs around edited workflows, possibly unsaved workflows, or which jobs/steps logs relate to.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our
Responsible AI Policy

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review
  with Claude Code)
• I have implemented and tested all related authorization policies.
  (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[github-actions]

Security Review ✅

• S0 (project scoping): New Invocation.logs_for_run/2 (lib/lightning/invocation.ex:914) joins run → work_order → workflow and filters on project_id; the message processor calls it with the trusted session.project_id (lib/lightning/ai_assistant/message_processor.ex:143), and channel-side sanitize_follow_run_id/2 (lib/lightning_web/channels/ai_assistant_channel.ex:607) drops any follow_run_id that Runs.get_for_project/2 cannot resolve within the authenticated project.
• S1 (authorization): N/A — no new web-layer actions; the modified join/new_message paths remain behind the existing check_project_access(project.id, user, :access_write) gate.
• S2 (audit trail): N/A — no configuration-resource writes; only chat sessions/messages and outbound Apollo requests are added.