Fix NoHandlerForEndpointException during concurrent saga chain compile

[Bishbulb]

Summary

I ran into this running saga workloads under dynamic codegen. At cold-start, when two messages for the same saga type arrived concurrently, one would sometimes throw NoHandlerForEndpointException even though a valid handler was about to be assigned on the other thread. I traced it to HandlerGraph.resolveHandlerFromChain.

Root cause

SagaChain.DetermineFrames calls Handlers.Clear() as a side effect of codegen before the generated handler gets registered.
resolveHandlerFromChain checks HasDefaultNonStickyHandlers() outside the compile lock:

  else if (!chain.HasDefaultNonStickyHandlers())   // read outside the lock
  {
      throw new NoHandlerForEndpointException(messageType);
  }
  else
  {
      lock (_compilingLock) { /* compile */ }
  }

A concurrent second caller arriving while the first is mid-compile sees the temporarily-empty Handlers, HasDefaultNonStickyHandlers() returns false, and the throw happens (even though the first thread is about to assign chain.Handler)

Note that this is only reproducible under dynamic codegen because pre-generated code doesn't hit this path.

Fix

Move the full "handler present / compile / throw" decision inside _compilingLock, with a fast-path re-check on chain.Handler for threads that arrived after compilation finished.