Fix started event id reported on workflow task poll in the test server

[sangkyoonnam]

What was changed

• StateMachines#startWorkflowTaskImpl now sets the poll response's startedEventId to the id of the WorkflowTaskStarted event that was actually added, instead of scheduledEventId + 1. The query-only path keeps its existing value.
• Added WorkflowTaskStartedEventIdTest in the test server module covering a signal that lands between WorkflowTaskScheduled and WorkflowTaskStarted.

Why?

The test server hardcoded the poll response's startedEventId as scheduledEventId + 1. When an event such as a signal lands between the scheduled and started events, that id points at the wrong event: for a history of WorkflowExecutionStarted(1), WorkflowTaskScheduled(2), WorkflowExecutionSignaled(3), WorkflowTaskStarted(4) the response reported 3. The real server reports the id of the started event itself (workflow_task_state_machine.go sets StartedEventID = startedEvent.GetEventId()), and the test server already tracks the correct value in data.startedEventId; only the response was wrong. SDKs use this value to verify a workflow task's history was replayed up to the started event (#1916), so a too-small value weakens that check, and the test server binary is shared by the Python, TypeScript, .NET and Ruby SDKs through Core's ephemeral server.

Checklist

1. No open issue for this.

2. How was this tested:
   New WorkflowTaskStartedEventIdTest starts a workflow, signals it before any poll, polls, and asserts the response's startedEventId equals the WorkflowTaskStarted event id in the returned history. Run with ./gradlew :temporal-test-server:test --tests "io.temporal.testserver.functional.WorkflowTaskStartedEventIdTest". It fails without the fix (expected:<4> but was:<3>) and passes with it. The test server module and the SDK signal, query, update, sticky and replay tests pass.

3. Any docs updates needed?
   No.