Add ability to gradually enable new getVersion/patched calls

[Sushisource]

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 - Add preferred version provider sdk-go#2446
• Java - Add preferred version worker option sdk-java#2941
• TypeScript -
• Python -
• .NET -
• Ruby - [Feature Request] Add patch activation callback sdk-ruby#480
• Rust -
• PHP -
• Temporal CLI -