.NET: Fix off-thread RunStatus race where GetStatusAsync can return Running after ResumeAsync halts

[Peter Ibekwe (peibekwe)]

Motivation and Context

In StreamingRunEventStream.RunLoopAsync, after every _inputWaiter.WaitForInputAsync wake-up, _runStatus was being flipped to Running unconditionally. This can lead stale signal to flip status back to running after consumer already observed halt signal.

Fixes#5411

Description

Only flip RunStatus to Running when there are messages to process.
LockstepRunEventStream is not affected — it runs supersteps synchronously on the consumer thread and has no comparable wake-up race.

This addresses one of the intermittent workflow test failures in the pipeline.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the Contribution Guidelines
• All unit tests pass, and I have added new tests where possible
• Is this a breaking change? If yes, add "[BREAKING]" prefix to the title of the PR.

[Copilot]

Pull request overview

Fixes a race in the off-thread workflow run loop where RunStatus could transiently flip back to Running after a halt had already been observed, and adds a stress regression test to prevent reintroduction.

Changes:

• Update StreamingRunEventStream.RunLoopAsync to set RunStatus.Running only when there are unprocessed messages to run.
• Add an off-thread stress regression test that repeatedly runs the Step9 sample to catch the previously intermittent status race.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
dotnet/src/Microsoft.Agents.AI.Workflows/Execution/StreamingRunEventStream.cs	Prevents stale input signals from transiently setting RunStatus back to Running when there is no work to process.
dotnet/tests/Microsoft.Agents.AI.Workflows.UnitTests/SampleSmokeTest.cs	Adds a stress regression test targeting the Step9 multi-response resume scenario in off-thread execution.

[Jacob Alber (lokitoth)]

Ah, guess I missed it, but for information purposes:

I remember looking at this earlier in #2646; when I added tests for this, I noticed that Lockstep was semantically different in how it handled things, so there were some things to be done to get it to a happy state, but may be out of scope of this PR.

Might be worth bringing over the tests though?

I'll bring over tests + any changes that are needed for them separately.