We should probably also have an upper bound of buffered logs since these will take up memory, or alternatively, store logs on disk until they can be sent.

If something goes wrong with a command, there's really no telling how much it will spit out, it could be KiB's or it could be GiB's (in extreme cases). We also have limits in place in the API that limit the output to 1 MiB, although I can't recall the details if we store both the head and tail end of logs or simply cutoff at 1 MiB.

Not a bad idea. Can address in a follow on PR.

I think this change here demonstrates a downside of using PR stacking too much. I don't think it's a good idea to split up an implementation like this, especially a new one (I might be of a different opinion for something much bigger).

Here is a change that introduces more advanced logic in a place where I left a simple suggestion in the previous PR. I think that comment applies here too (as in we don't need a clone of the slice, we can utilize the backing array/append semantics). But based on the comment from my previous PR, this may be easily overlooked due to the change in this one.

How about truncating instead of dropping entirely?