Add ability to gradually enable new getVersion/patched calls

Is your feature request related to a problem? Please describe.

getVersion(changeId, minSupported, maxSupported) always picks maxSupported for a new run and patched() always enables the patch on a non-replay run. So the instant a worker with new code is deployed, every new workflow on it runs the new version. During a rolling deploy this causes three problems:

1. You can't stage code. Pushing code to the fleet and activating it are one event — there's no "deploy everywhere first, turn on later."
2. Misrouting causes failures. Mid-deploy the fleet is mixed. A workflow that memoized the new version can land on an old worker that doesn't support it; getVersion throws UnsupportedVersion and the task fails. It recovers on retry, but the failures fire alerts.
3. No ramp. You can't move new runs onto the new version gradually (10% → 50% → 100%). It's all-or-nothing per worker.

The root cause: getVersion conflates capability (which versions a worker can run) with activation (which version new runs start on).

Describe the solution you'd like

Introduce a worker-level option that allows specifying a callback which can determine the "preferred" version to be used (or whether or not to enable the patch) the first time the new call is hit.

Additional context

Per-SDK Tickets

• Go - https://github.com/temporalio/sdk-go/issues/2446
• Java - https://github.com/temporalio/sdk-java/issues/2941
• TypeScript -
• Python -
• .NET -
• Ruby - https://github.com/temporalio/sdk-ruby/issues/480
• Rust -
• PHP -
• Temporal CLI -

Start with the getVersion and patched entry points described in the issue, then compare the linked per-SDK tickets to determine the shared worker-level callback behavior. Define how preferred versions and patch activation are selected during rolling deploys, and verify that the design supports staged activation without UnsupportedVersion failures.