Buffer a new workflow task while the run already has one

[THardy98]

What was changed

Core now holds a new workflow task back while the run already has one open, not only while the SDK is busy. One line in buffer_wft_if_outstanding_work: || self.wft.is_some(). The method's doc comment already said it buffers while a workflow task is outstanding.

The test shows the bug it fixes:

1. A workflow task arrives, and the workflow starts a local activity.
2. While the local activity runs, a query arrives as its own task. (This is agnostic to queries; any task arriving then would do the same.)
3. Core should hold the query until the workflow task is done. Without the fix, it handles the query right away and loses track of the workflow task, failing on core's own check: "Trying to send a new WFT for a run which already has one!"

With the fix, the query waits, the workflow task is reported, and then the query is answered.

Why?

Core held a new task back only while the workflow was busy, meaning the SDK was processing an activation or work was queued. Since #1442, core answers the SDK right away while local activities run, so a workflow waiting on a local activity didn't look busy. A query arriving in that gap was handled immediately and replaced core's record of the workflow task.

Core never completed the lost workflow task, so it timed out on the server (10 seconds by default). The retry then often failed with a nondeterminism error, Invalid transition while handling update response ... in state CompletedImmediatelyCompleteCreated, and the workflow stayed stuck.

We hit this in load tests on Temporal Cloud (throughput_stress, 40 concurrent workflows, 1 hour). Per run:

SDK	"already has one"	Nondeterminism errors	Runs that hung
.NET	92-112	19-33	7 of 7
Python	2-8	0-4	2 of 7
TypeScript	0-2	0-2	0 of 7

Every nondeterminism error followed an "already has one" in the same workflow run, about 10 seconds earlier. Debug logs from an earlier Python run showed the replacing task was a legacy query, as in this test.

Load test with the fix: .NET on Core main against Core main plus this fix, 10 runs each (throughput_stress, 40 concurrent workflows, 20 minutes):

.NET build	Runs completed	"already has one" per run	Nondeterminism errors per run
Core main (aefe3059)	1 of 10	23-51	3-15
Core main + this fix (74b68df0)	10 of 10	0	0

Checklist

1. Closes

2. How was this tested:

   • The test fails without the fix and passes with it (30 of 30 runs):
     cargo test -p temporalio-sdk-core --test integ_tests --features temporalio-common/serde_serialize,test-utilities,ephemeral-server,temporalio-sdk/experimental,temporalio-sdk-core/otel -- legacy_query_while_waiting_on_la_is_buffered
   • Core's unit tests pass (cargo test -p temporalio-sdk-core --lib), and so do the local activity, query and update integration tests (cargo integ-test local_activities, queries_tests, update: 97, 8 and 44 tests).
   • cargo lint is clean.
   • Added entries under Unreleased / Fixed in CHANGELOG.md and crates/sdk-core/CHANGELOG.md.

3. Any docs updates needed?
   No.

🤖 Generated with Claude Code