Track Durable Task middleware support across language SDKs

Summary

Track cross-SDK rollout of Durable Task middleware support after the .NET reference implementation.

Reference spec: https://github.com/microsoft/durabletask-dotnet/blob/feature/durable-task-middleware/doc/cross-sdk-middleware.md
.NET user guide: https://github.com/microsoft/durabletask-dotnet/blob/feature/durable-task-middleware/doc/durable-task-middleware.md
.NET feature branch: https://github.com/microsoft/durabletask-dotnet/tree/feature/durable-task-middleware
Motivation: https://github.com/Azure/azure-functions-durable-extension/issues/3054

The .NET implementation is the reference for the v1 behavior and API contract. Other SDKs should use language-idiomatic names and shapes while preserving the durable middleware model described in the spec.

Child issues

• JavaScript / TypeScript: https://github.com/microsoft/durabletask-js/issues/242
• Python: https://github.com/microsoft/durabletask-python/issues/136
• Java: https://github.com/microsoft/durabletask-java/issues/285
• Go: https://github.com/microsoft/durabletask-go/issues/132

PowerShell is not tracked as a separate SDK target because it inherits applicable .NET behavior.

Shared v1 scope

• Orchestration middleware.
• Activity middleware.
• Per-worker or per-builder registration.
• Type/class and/or delegate/function middleware registration where idiomatic.
• Host feature collection for per-work-item host context.
• Orchestration replay-determinism guidance and illegal non-durable await guard expectations where feasible.
• Activity short-circuiting through an explicit result-setting API.

Out of scope for v1

• Entity middleware.
• Wire protocol or protobuf changes.
• Replacing host worker middleware abstractions such as Azure Functions worker middleware.

Completion criteria

Close this issue when each child SDK issue has a merged implementation or the owning SDK has explicitly decided to track or defer the work elsewhere.

Start by reading the cross-SDK middleware spec, the .NET user guide, and the .NET feature branch listed in the issue. Then review child issues 242, 136, 285, and 132 for JavaScript/TypeScript, Python, Java, and Go. Done means each child issue has a merged implementation or an explicit decision to track or defer the work elsewhere.