[Cross-SDK] Expose portable worker connection and lifecycle status

Summary

Portable Durable Task workers generally report startup success before they have
connected to the backend. Today, customers do not have a supported API for
observing the worker's lifecycle or connection state and must infer it from logs.

This feature request asks for a consistent, public way across the .NET, Python,
Java, and JavaScript/TypeScript SDKs to determine whether a worker is starting,
connected, reconnecting, stopping, stopped, or permanently faulted.

Customer problem

Customers running workers in Kubernetes, Azure Container Apps, worker services,
or other self-hosted environments may want to:

• expose an application readiness or health endpoint;
• wait for a worker connection before accepting dependent work;
• alert when a worker has been disconnected for too long;
• coordinate shutdown, failover, or custom lifecycle management; and
• distinguish "the worker loop was launched" from "the backend connection is active."

Parsing log messages is not a stable API, and transport channel state alone does
not prove that the worker's GetWorkItems stream is active.

Desired outcome

Provide at least one supported, typed mechanism for customers to observe worker
lifecycle and backend-connection state, with equivalent semantics across the
portable SDKs.

Existing startup behavior does not need to change. In particular, this request
does not require start() or host startup to block until connected.

Design options to consider

The following are alternative or independently adoptable approaches. This
feature does not require implementing all of them.

1. Pollable status snapshot
   Expose a current status/state property, potentially with timestamps and the
   last sanitized connection error.

2. Status transition notifications
   Expose an idiomatic event, listener, callback, observable, or async iterator
   for customers that do not want to poll.

3. Explicit wait helper
   Add an opt-in WaitUntilConnected/wait_until_connected API with timeout and
   cancellation, while preserving nonblocking startup by default.

4. Protocol-backed readiness
   If local SDK signals are not strong enough, add an explicit backend
   acknowledgment that the work-item stream has been accepted and registered.
   This would be a larger, separately coordinated protocol change.

Possible common states include NotStarted, Connecting, Connected,
Reconnecting, Stopping, Stopped, and terminal Faulted. Exact naming and
which option provides the best cost/value tradeoff are open for design.

Scope

• Align semantics across durabletask-dotnet, durabletask-python,
  durabletask-java, and durabletask-js.
• Avoid requiring customers to parse logs or consume raw gRPC/protobuf types.
• Clearly distinguish transient reconnecting from a worker loop that has
  permanently terminated.
• Document what "Connected" or "Ready" proves and how quickly a half-open
  connection is detected.

Detailed cross-SDK findings and design tradeoffs are included in a follow-up
comment.

Related work

• https://github.com/microsoft/durabletask-js/issues/69
• https://github.com/microsoft/durabletask-js/pull/353
• https://github.com/microsoft/durabletask-python/issues/175
• https://github.com/microsoft/durabletask-python/pull/176
• https://github.com/microsoft/durabletask-dotnet/issues/336

Start with the detailed cross-SDK findings in the follow-up comment and review the related durabletask-js, durabletask-python, and durabletask-dotnet issues and pull requests. Define equivalent typed lifecycle and connection semantics across the four SDKs, including what Connected or Ready proves; done means customers can observe state without parsing logs and transient reconnects are distinguishable from permanent termination.