Document SynchronizationContext behavior in .NET isolated worker

Add a new 'Async programming' section to the isolated worker guide that
documents:
- The isolated worker does not set a SynchronizationContext
- ConfigureAwait(false) has no practical effect in function code
- The same async/await behavior as standard .NET console/ASP.NET Core apps
- A note about Durable Functions orchestrator threading constraints

Addresses Azure/azure-functions-dotnet-worker#1520

Co-authored-by: Copilot <[email protected]>

Author: kshyju

articles/azure-functions/dotnet-isolated-process-guide.md

@@ -3,7 +3,7 @@ title: Guide for running C# Azure Functions in an isolated worker process
 description: Learn how to use the .NET isolated worker model to run your C# functions in Azure, which lets you run your functions on currently supported versions of .NET and .NET Framework.
 ms.service: azure-functions
 ms.topic: how-to
-ms.date: 12/06/2025
+ms.date: 02/24/2026
 recommendations: false
 ms.custom:
   - template-concept
@@ -596,6 +596,15 @@ The cancellation token is signaled when the function invocation is canceled. Sev
 
     This exception occurs when the cancellation token is canceled (as a result of one of the events described earlier) _before_ the host sends an incoming invocation request to the worker. This exception can be safely ignored and is expected when `SendCanceledInvocationsToWorker` is `false`.
 
+## Async programming
+
+The .NET isolated worker doesn't set a custom [`SynchronizationContext`](/dotnet/api/system.threading.synchronizationcontext). This means that `SynchronizationContext.Current` is `null` during function execution. After an `await`, continuations are scheduled on the thread pool, which is the standard .NET behavior.
+
+Because there's no `SynchronizationContext` to suppress, using [`ConfigureAwait(false)`](/dotnet/api/system.threading.tasks.task.configureawait) in your function code has no practical effect. The isolated worker process runs as a standard .NET generic host (console app), so the same async/await behavior you'd expect in any ASP.NET Core or console application applies here. This is also true for .NET Framework (net48) isolated worker apps, since the worker process is always a console executable using `HostBuilder`.
+
+> [!NOTE]
+> [Durable Functions](/azure/azure-functions/durable/durable-functions-overview) orchestrators have their own threading constraints. The orchestrator replay thread must run continuations, so using `ConfigureAwait(false)` in orchestrator functions or orchestrator middleware can interfere with orchestration execution. For more information, see the [Durable Functions code constraints](/azure/azure-functions/durable/durable-functions-code-constraints).
+
 ## Bindings 
 
 Define bindings by using attributes on methods, parameters, and return types. Bindings can provide data as strings, arrays, and serializable types, such as plain old class objects (POCOs). For some binding extensions, you can also [bind to service-specific types](#sdk-types) defined in service SDKs.