TS/runtime-5: align virtual/real time in all types of scheduled task category

[feiyang3cat]

What changed?

• mutable_state_impl.go
  • AddTasks: drop-check gate widened to all CategoryTypeScheduled tasks (was timers only); comparison
    uses ms.Now() (virtual) instead of wall.
  • New ToRealTime(virtual) → wall centralizes the conversion.
  • SetSpeculativeWorkflowTaskTimeoutTask converts to wall via ToRealTime before enqueuing.
  • accumulatedSkippedDuration simplified to nil-safe proto getter.
• timer_queue_{active,standby}_task_executor.go: heartbeat-dedup compares wall-vs-wall via
  ToRealTime(heartbeatTimeoutVis) (was mixed frames), and use ms.Now instead of t.Now for activity timeout/user timer time check
• task_generator.go: TODO marking ChasmTaskPure / HSM-timer regeneration as not yet supported.
• interfaces/mutable_state.go: adds ToRealTime; documents virtual-frame contract on AddTasks,
  Now, SetSpeculativeWorkflowTaskTimeoutTask.

Why?

Under time skipping, virtual time inside mutable state can run ahead of wall time, but scheduled-task
firing still runs on wall time. Each crossing needs explicit conversion:

• Tasks leaving mutable state for the scheduled-task queues must be converted to wall time.
• Validation of generated/fired tasks must reference virtual (mutable-state) time.

Before this change, virtual and wall values were silently compared — harmless pre-skipping, but now lets
the wrong tasks get dropped/kept and stale heartbeat tasks pass dedup.

How did you test it?

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

[feiyang3cat]

needs a bit attention

for all executions (the majority won't have timeskipping), the reference time is still delayed to when actionFn runs, and this may be a few us/ms delay depending on the cache miss/hit. right now I judge it as safe and no correctness risks

there is another way to do this is to change the referenceTime only when the mutableState has TimeSkippingInfo set, and I am not taking this path now for simplicity

[feiyang3cat]

though we add other scheduled timer task types in, the executors of archival and speculative tasks don't validate the fire time, so for those tasks the executor files are untouched