Add schedule_to_start_timeout to WorkflowTaskScheduledEvent

[saad1998]

What changed?

• Populate schedule_to_start_timeout on WorkflowTaskScheduledEventAttributes whenever the server applies a schedule-to-start timeout (sticky task queue or speculative workflow task on normal queue).
• Event factory and history builder: added optional scheduleToStartTimeout parameter to CreateWorkflowTaskScheduledEvent AddWorkflowTaskScheduledEvent.
• Workflow task state machine: all call sites that create WorkflowTaskScheduled events now pass the timeout from GetWorkflowTaskScheduleToStartTimeout() when applicable (sticky or speculative); otherwise pass nil.
• GetTransientWorkflowTaskInfo: transient scheduled event attributes now include ScheduleToStartTimeout when the task queue is sticky or the workflow task is speculative.
• History builder tests: added the new optional argument (nil) where the builder is called.

Depends on temporalio/api adding the schedule_to_start_timeout field to WorkflowTaskScheduledEventAttributes (e.g. API PR temporalio/api#710 ). This PR will not build until that API PR is merged; then run make update-go-api and push to refresh dependencies.

Why?

Fixes #778. The server enforces a schedule-to-start timeout (e.g. 5s for speculative WT, or the sticky timeout) but the event did not record it, so UIs could show a different value and users saw timeouts earlier than expected. Recording the timeout on the event makes server behavior visible and consistent for clients and UIs.

How did you test it?

• built
• run locally and tested manually
• [x ] covered by existing tests
• added new unit test(s)
• added new functional test(s)

Potential risks

Low: new field is optional; existing history and clients are unchanged. Server logic (timer creation) was already correct; this only records the same value in the event.