FIX: streamify was appending StatusStreamingCallback directly to the shared settings.callbacks list

[glesperance]

Fix streaming status message callback mutation

Bug
streamify was appending StatusStreamingCallback directly to the shared settings.callbacks list.

That list was mutated in place and reused across calls, callbacks (and their status message providers) leaked between different dspy.streamify(...) invocations.

Fix
Each call to streamify now works on an isolated callback list by copying the global callbacks before modification.

This prevents callback leakage between programs, ensures that custom status message providers only affect the specific program they are passed to, and restores the correct, deterministic status message behavior required by the tests.

[chenmoneygithub]

Thanks for spotting the bug and putting up the PR!

[glesperance]

@chenmoneygithub just bumping this in case you missed the notif about the new commit fixing the issue you brought up

[chenmoneygithub]

Thank you for the updates and reminder! One comment about the testing, then it should be good to go!

[chenmoneygithub]

We may want to refactor the testing a bit - instead of default => custom, we can put up two threads that apply different MyStatusMessageProvider, and verify that both threads work as expected. Then at the end we verify that the callback is not being modified.

[glesperance]

@chenmoneygithub The latest commit incorporates your feedback on the tests. Please let me know if you see anything else that needs adjustment.

Just flagging this touches a production bug -- ie we're running on our fork but looking forward to moving back to main whenever you get a chance to review.