Support batched logs from the worker

[josephjclark]

Background

The production worker now supports batch logging (optionally).

What this means in short that instead of sending each log line straight to the run:socket channel, it'll save up a bunch of them and send a batch of logs in one go.

This should reduce latency on log processing in the worker, and may eliminate even more lost runs.

Overview

This is a very simple, minimal PR which supports log events being set from the worker in batches.

It is designed to be backward compatible with batched and un-batched logs.

So basically the behaviour here is is simply:

• Always handle log events as an array of logs (under the logs key)
• If receiving a "legacy" event, without a logs, key, massage the payload into an array of 1 log
• Process the logs one at a time

This PR does not do any batch uploading in the database. It probably makes sense to do this? But it feels beyond the scope of what I ought to be doing (with or without Claude's help)

I have not touched tests, but we should introduce a few tests against batched logs.

Closes #4123

AI Usage

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

• Code generation (copilot but not intellisense)
• Learning or fact checking
• Strategy / design
• Optimisation / refactoring
• Translation / spellchecking / doc gen
• Other
• I have not used AI

You can read more details in our Responsible AI Policy

[josephjclark]

Hey @stuartc - this is all I've done on the lightning so far for batch logging. Just enough for local testing really.

There's a lot of work we could do here to improve. I don't know how much appetite we have?

[josephjclark]

Hi @midigofrank - as Stu is going to be tied up until the end of the year, can you help me with this? CC @theroinaochieng