Mapper fabricates Date(0) for missing timestamps — silent server contract violations

[daohhuynh]

Summary

mapInboundMessage and mapStatusUpdate use ?? new Date(0) as a fallback for missing proto.timestamp. The proto declares timestamp as required, and the public
TypeScript type at src/types/events.ts:56 types it as non-optional Date. So this fallback only fires on a server contract violation. When that happens the violation is
silently swallowed: consumers see 1970-01-01T00:00:00.000Z with no diagnostic.

Code references

src/transport/mapper.ts:411:

timestamp: proto.timestamp ?? new Date(0),                

src/transport/mapper.ts:635:

timestamp: proto.timestamp ?? new Date(0),

src/types/events.ts:56: declares timestamp as non-optional Date.

Suggested fix

Two options:

1. Throw on missing timestamp — surfaces the contract violation to consumers loudly
2. Widen the public type to Date | undefined — forces consumers to handle the missing case explicitly

Either is better than silently fabricating. Recommend option 1 since the proto contract says required.

Severity

Low. Server isn't supposed to violate this contract. But if it does, downstream displays (sorting, "last activity" timestamps, dashboards) will silently show 1970 dates with
no diagnostic indicating the cause.