Add patch activation callback

[Sushisource]

What was changed

Added an experimental TemporalWorkerOptions.PatchActivationCallback that lets a worker decide whether the first newly encountered, non-replay Workflow.Patched call activates a patch.

The callback receives 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.

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

The work is intentionally split into two commits:

1. Add patch activation callback contains only the callback API, plumbing, activation semantics, and rollout tests.
2. Harden read-only workflow contexts makes the callback read-only and completes the workflow context's read-only enforcement. This includes guarding nested patches, workflow metadata and handler mutation, continue-as-new, and patch calls from queries and update validators.

Note

We can drop the second commit if it feels like too much to put in the PR, but, it's done and I think adds some nice safety.

Why?

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

Keeping the read-only hardening in a subsequent commit separates the callback's intended behavior from the broader workflow-context consistency fixes discovered during review.

Testing

• .NET SDK build across all target frameworks with zero warnings
• First callback-only commit independently formatted and tested
• 21 focused callback, read-only, mutation, handler, query, and update-validator cases
• Changed-file formatting verification
• Diff and sdk-core submodule cleanliness checks