[copilot-finds] Bug: newOrchestrationState() defaults missing timestamps to current time instead of epoch, inconsistent with batch query API

[github-actions]

Problem

newOrchestrationState() in packages/durabletask-js/src/orchestration/index.ts (lines 34-35) initializes timestamp fallbacks as new Date() (current time) when the protobuf response has no createdtimestamp or lastupdatedtimestamp:

let tsCreatedParsed = new Date();   // current time
let tsUpdatedParsed = new Date();   // current time

However, _createOrchestrationStateFromProto() in client.ts (lines 1243-1244) uses new Date(0) (epoch):

const createdAt = createdTimestamp ? createdTimestamp.toDate() : new Date(0);
const lastUpdatedAt = lastUpdatedTimestamp ? lastUpdatedTimestamp.toDate() : new Date(0);

This means the same orchestration queried via getOrchestrationState() vs getAllInstances() can produce different timestamp values when the protobuf lacks timestamps.

Additionally, lines 51-52 create unnecessary new Date() copies of values that are already Date objects (new Date(tsCreatedParsed) when tsCreatedParsed is already a Date).

Root Cause

The two code paths for constructing OrchestrationState from protobuf were written at different times and chose different fallback strategies for missing timestamps.

Proposed Fix

• Change the fallback from new Date() to new Date(0) in newOrchestrationState(), matching the behavior of _createOrchestrationStateFromProto().
• Remove the redundant new Date() wrappers on lines 51-52 since the values are already Date objects.

Impact

• Severity: Low-medium. Produces misleading timestamp data (appears as "just now" instead of clearly indicating a missing value) for orchestrations queried via single-instance APIs.
• Scenarios affected: getOrchestrationState(), waitForOrchestrationStart(), waitForOrchestrationCompletion() — when the sidecar response lacks timestamp fields.
• Related: Similar class of bug as [copilot-finds] Bug: convertEntityMetadata() defaults missing lastModifiedTime to current time instead of epoch #240 (convertEntityMetadata), but in a different function affecting different APIs.