fix(output): synchronize concurrent writes to the prefixed writer

[ikshantshukla123]

Description #2945

This pr fixes a panic that can happen with output: prefixed mode. when a task writes to both stdout and stderr at the same time, the same prefixWriter ends up being used from two goroutines (os/exec copies each stream from its own goroutine) the shared bytes.Buffer is not safe for concurrent use, so this could corrupt its state and crash with a "slice bounds out of range" panic when their is multiple stdout and stderr concurrently.I added a mutex to prefixWriter and lock it in both Write and Close so the buffer is only ever touched by one goroutine at a time.
I also added a regression test that writes 1000 lines to stdout and 1000 to stderr concurrently, then checks that we get exactly 2000 correctly prefixed lines back. I confirmed it panics without the fix, and passes with it (also clean under -race).

Notes

• I'm aware fix: synchronize prefixed output writer to fix concurrent-write panic #2949 was closed earlier for not following the AI usage policy.
  The mutex approach i used was suggested in the issue comments by @trulede sir;
  I've reviewed the code and tests myself and can explain any part of it.
• Chatgpt assistance was used.

Checklist

• I have read and followed the Contribution Guide.
• I have disclosed the use of any AI generated content in this pull
  request per the AI Usage Policy.
• I fully understand the changes and have hand written the description
  (No AI) of this pull request.

and also I have used strings.Split as i found it is used across the repo in (e.g. task_test.go, watch_test.go etc).and it is a completely standard import for test assertions. output_test.go didn't need it before only because the existing tests there used assert. Equal on exact strings rather than splitting or parsing output.

Ready for further discussions.

[trulede]

The test might be useful during development but is otherwise useless. Why did you include it again?

[ikshantshukla123]

The test might be useful during development but is otherwise useless. Why did you include it again?

okay okay apology you already flagged this in #2949 and I missed it. I will limit the test when it runs like I will move the concurrency test into its own file gated with go:build race, so it only executes under race and never runs in plain CI.
should i go with this or just drop the test?