[Feature Request] Endtoend latency metric for cron executions

Currently workflow_endtoend_latency SDK metric uses WorkflowExecutionStarted event time:
https://github.com/temporalio/sdk-go/blob/master/internal/internal_task_handlers.go#L1580
https://github.com/temporalio/sdk-java/blob/master/temporal-sdk/src/main/java/io/temporal/internal/replay/ReplayWorkflowExecutor.java#L114

for calculation of the exec"start time".
For cron workflows this can lead to very large endtoend latencies as the first workflow task is not added to tq until firstWorkflowTaskBackoff timer fires.

Request here is to either subtract the firstWorkflowTaskBackoff duration from reported workflow_endtoend_latency metric if that is indeed its intention (to measure actual time worker processes workflow exec).
If not, then to add a new metric maybe that denotes this, for example workflow_firsttask_to_close_latency or something similar.
Other ideas:
distinguish via:
workflow_starttoclose_latency (would be as current workflow_endtoend_latency)
workflow_scheduletoclose_latency (would be workflow_endtoend_latency - firstWorkflowTaskBackoff)

or workflow_cron_execution_latency

Start by comparing the workflow_endtoend_latency handling at internal/internal_task_handlers.go:1580 in the Go SDK and temporal-sdk/src/main/java/io/temporal/internal/replay/ReplayWorkflowExecutor.java:114 in the Java SDK. Clarify whether cron backoff should be excluded or represented by a new metric, then validate the chosen semantics with the repository's behavior and history compatibility tests; done means the metric behavior and naming are agreed across SDKs.