You are witnessing workflow caching (aka sticky workflow execution) in action.
Task queue (the Temporal name for Cadence task lists) deliver tasks to any worker that polls it. This leads to situation that caching workflow state at a worker is not feasible as workflow tasks destined to a given workflow execution can be sent to any other worker any time.
Temporal solves this is by requiring every workflow worker to listen on two workflow (aka decision) task queues. One with the name you gave it (T0 in your case) and one with automatically generated process specific name.
When a workflow worker receives a task on a shared task list it executes it and caches the workflow state in its LRU cache. Then it includes the host specific task queue name into the task reply call.
Then the history engine starts using the host specific queue name to schedule workflow tasks after that. This is what you see in the posted event history. As the queue name is host specific only the host that cached the workflow state receives this tasks.
The shared tasks queues have schedule to start timeout equal to workflow-run-timeout as timing them out before the whole workflow timeout doesn’t really make sense. Host specific task queues on the contrary have a short schedule-to-start timeout (default is 5 seconds) to deal with worker process failures. When a task in a host specific task queue times out it is immediately rescheduled to a shared task list for other hosts to pick up.