Add patch activation callback

[Sushisource]

What was changed

Added an experimental WorkerOptions::patch_activation_callback for native Rust workflows that lets a worker decide whether the first newly encountered, non-replay patched call activates a patch.

The callback receives owned, immutable PatchActivationInput containing workflow information and the patch ID. Its boolean decision is memoized for the workflow run. Declined patches return false without recording a marker, while replay, existing history markers, and deprecated patches retain their existing behavior.

WASM component workflows are intentionally excluded because supporting the host callback there requires a WIT/generated-interface expansion.

This ports the behavior introduced by temporalio/sdk-ruby#481.

Why?

This allows workflow changes using patched to roll out gradually without every new-code worker immediately recording a marker that older workers cannot replay.

Testing

• cargo test -p temporalio-sdk --lib
• cargo test -p temporalio-workflow patch_activation
• cargo lint
• cargo test-lint
• cargo integ-test workflow_tests::patches: 33 cases
• Nightly formatting and diff cleanliness checks

[chris-olszewski]

Implementation looks good. My one concern is around exposing WorkflowContextView::new as is. Understand it is doc hidden, but it is easy enough to find in an IDE. A free function would be less discoverable or we could at least make it clear not to depend on it.

[chris-olszewski]

I understand we need someway to drive the patch activation from workflow_wasm, but I don't love exposing this interface as is. The triple Strings are begging for arg mixups.

Maybe a new small struct that carries namespace/task queue/run id and introduce a new call_patch_activation_callback(callback, workflow_info, init) here that is public hidden and handles the PatchActivationInput/WorkflowContextView construction. Still public, but harder to misuse.