Add Durable Task middleware support

[cgillum]

Summary

Track adding SDK-level Durable Task middleware support to the JavaScript/TypeScript SDK, aligned with 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
Motivation: Azure/azure-functions-durable-extension#3054

The spec may shift until the .NET v1 implementation is merged. This issue is intended to track the JS/TS design and implementation work so it can follow the same durable middleware contract with idiomatic API names.

Proposed shape

Names are illustrative, not final API commitments.

worker.useOrchestrationMiddleware(async (ctx, next) => {
  if (!ctx.isReplaying) {
    ctx.logger?.info("starting orchestration", {
      name: ctx.name,
      instanceId: ctx.instanceId,
    });
  }

  await next(ctx);
});

worker.useActivityMiddleware(async (ctx, next) => {
  const cached = await cache.tryGet(ctx.name, ctx.input);
  if (cached !== undefined) {
    ctx.setResult(cached);
    return;
  }

  await next(ctx);
});

Design points to cover

• Worker-level registration APIs for orchestration and activity middleware.
• Registration ordering: first registered middleware runs outermost and unwinds last.
• Context interfaces that expose durable task name, instance ID, version/parent/tags where available, input, raw input where available, replay state for orchestrations, features, and result after next.
• A typed or symbol-keyed feature map for host-specific per-work-item objects.
• Orchestration middleware determinism guidance for replay, including replay-safe logging and avoiding non-durable promises/awaits, timers, random values, wall-clock time, file/network I/O, and mutable process state.
• Activity middleware short-circuiting through an explicit setResult API.
• Host integration pattern for Azure Functions or other hosts to attach invocation context through features instead of durable middleware depending on host middleware internals.

Acceptance criteria

• Orchestration and activity middleware APIs are exposed at the durable worker/app level.
• Middleware executes in registration order and unwinds in reverse order.
• Orchestration middleware must call next(ctx) exactly once when completing successfully; missing or duplicate calls are rejected where feasible.
• Activity middleware can call next(ctx) once or short-circuit only through ctx.setResult(...); duplicate next is invalid.
• Host-specific objects can be passed through features without serialization into durable history.
• Documentation covers replay determinism and the difference between durable middleware and host/Functions middleware.
• Tests cover registration ordering, context population, feature access, orchestration next-call validation, and activity short-circuiting.
• No wire protocol or protobuf changes are required.
• Entity middleware is out of scope for v1.