Missing shard ownership check in speculative workflow task processing may cause incorrect update rejections

Expected Behavior

Speculative workflow task processing should verify shard
ownership before completing, ensuring that workflow update
requests are not rejected due to stale mutable state caused
by a shard ownership change mid-execution.

Actual Behavior

No shard ownership check is performed during speculative
workflow task processing. If shard ownership changes
mid-execution, the task completes on stale mutable state,
causing valid workflow update requests to be incorrectly
rejected with no error logged.

Steps to Reproduce the Problem

1. Set up a Temporal cluster with multiple history service
   instances sharing shard ownership
2. Submit a workflow with pending update requests
3. Trigger a shard ownership transfer mid-speculative-WFT
   (e.g., restart a history pod)
4. Observe workflow updates incorrectly rejected despite
   being valid

Specifications

• Version: latest main
• Platform: any
• Affected file: service/history/workflow/workflow_task_state_machine.go:759
• Related API: AssertShardOwnership (fully implemented in persistence layer)