Shutdown task loss prevention

[Sushisource]

What was changed

• Introduces a ShutdownWorker RPC at the Worker level (previously only called from WorkflowWorker for sticky queues) covering all task queue types (workflow, activity, nexus), so the server
  knows the worker is going away and can stop dispatching tasks to it.
• Adds a per-worker workerInstanceKey (UUID) sent on every poll request, allowing the server to correlate polls with the shutdown signal.
• When the server advertises the workerPollCompleteOnShutdown capability, pollers wait for outstanding long-polls to complete naturally (server returns empty responses) instead of forcibly
  interrupting them. This prevents tasks that were dispatched to the worker just before shutdown from being lost.
• On shutdownNow() (forceful/interrupt path), the ShutdownWorker RPC is still fired but not awaited — poller teardown proceeds immediately without blocking on the server response.
• For older servers that don't support the capability, behavior is unchanged: polls are forcibly cancelled with a 1-second timeout.
• Replaces the per-worker AtomicBoolean serverSupportsAutoscaling with a shared NamespaceCapabilities object populated from DescribeNamespace at factory startup.

Why?

Prevents possible task loss during the shutdown process. Equivalent to: temporalio/sdk-core#1122

Checklist

1. Closes

2. How was this tested:
   Added test, existing tests.

3. Any docs updates needed?

[yuandrew]

Instead of calling namespaceCapbilities.set* for each field, could we have a generic namespaceCapabilities.populateFrom(describeNamespaceResponse), that way we don't need a separate if statement for each capability we want to capture?

[Sushisource]

Ya, good call

[yuandrew]

Can this potentially hang forever, if the server never responds?

[Sushisource]

I don't believe so, since new polls should not get initiated... but I added a generous timeout just in case.

[yuandrew]

Overall LGTM, looks like there's a CI issue with GracefulPollShutdownTest.java

[yuandrew]

Sorry blocking this for now, actively investigating a potential bug in the Core implementation