[SDK] Decide how datetimes are represented in the SDKs and the core library #1125

Summary

UTCDateTimeSchema and OffsetDateTimeSchema coerce to JS Date objects. Two separate signals say that is wrong: the Pennsylvania API hit friction with the coercion and would rather have validated strings, and the TS plugin work suggests the core library's datetime representation may need more precision than Date carries.

Note this pulls against #1016, closed by PR #1024, which fixed date-only round-tripping by introducing a PlainDate class. Date-only values are already handled; this is about datetimes, and the proposed direction (keep strings, drop the coercion) is the opposite of the one already shipped.

Acceptance criteria

• A decision on datetime representation is recorded, covering both the SDK schemas and whether the core library needs more precision
• The decision is reconciled with the PlainDate approach from fix(ts-sdk): preserve plain dates in JSON #1024
• Any resulting public contract change is marked as breaking for Release Please
• How the Python SDK represents datetimes is checked, and the decision says whether Python needs a matching change. If it does, a Python SDK ticket is created for that work