Experiment with streaming cloning

[josephjclark]

Over in #1458 we're focusing on making the "is this state object too big" calculation robust.

That approach uses :

• json-stream-stringify to serialize state to a string, throwing if the object exceeds a certain limit
• JSON.parse to convert the serialized string back to a JS object.

It is not memory efficient (which can be a problem for memory hungry workflows). The JSON.parse call is blocking and I think can cause the node process to consume too much memory, triggering kubernetes OOMkills.

This PR tries a fully streaming approach:

• use json-strream-stringify to stream a state object into a JSON string
• pass that into a pipeline which throws if the JSON string gets too long
• stream valid chunks directly into a new object

This should significantly reduce the memory overhead of this serialisation,

However! It significantly increases the time: it take 3.8 second to do what #1458 does in 0.9 seconds. I should note that these are pretty large state objects. I also reckon my CPU fan runs louder, implying more CPU usage. This makes semse to me because we're running the seriaisation in JS land, not C land.

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

[josephjclark]

I am tempted to say that cgroups are a better solution than this

I don't care why memory limits blow right now. If anything in the workflow causes memory to get too high, the node process must terminate gracefully and immediately. Even if this PR fixes this one corner case (at the cost of performance and compute), there are others that might trigger memory errors.

So I think I'll close this but keep the branch, then go and look at cgroups