Fix concurrent local activity replay nondeterminism

[paulcacheux]

Problem

When multiple coroutines issue local activities concurrently (e.g. via asyncio.gather), replay can fail with NondeterminismError.

During first execution, local activity resolve_activity jobs arrive in completion order (wall-clock timing). During replay, they arrive in sequence number order. This ordering difference causes coroutines to resume in a different order, assigning different sequence numbers to subsequent commands, which no longer match the recorded markers.

Fix

Sort local activity resolve_activity jobs by sequence number before processing them in _WorkflowInstanceImpl.activate(). This ensures coroutines always resume in scheduling order regardless of execution mode (first-execution vs replay).

The fix is safe for existing workflows:

• Without concurrent local activities: sorting a single item is a no-op.
• With concurrent local activities that replayed correctly (completion order happened to match seq order): the new code produces the same interleaving.
• With concurrent local activities that already failed on replay: they were hitting NondeterminismError anyway.

Test

Added test_workflow_concurrent_local_activity_replay: runs a workflow with two concurrent coroutines each issuing multiple sequential local activities, then replays the recorded history. Without the fix, replay fails with NondeterminismError.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}