Honour the time-precision extension on dateTime, time and Period boundaries

[alexzautke]

Why

FHIR dateTime and time require minutes and seconds once an hour is present, but CQL allows hour- and minute-precision values (@2005-05-10T10, @T10). An engine that returns valid FHIR from $cql therefore has to zero-pad the missing components, and the FHIR extensions pack provides time-precision (trial-use, value set of UCUM time-duration codes) to declare the real precision on the primitive element (_valueDateTime, _valueTime, _start, _end).

Firely Server (via the Firely CQL SDK) emits exactly that, and today the runner reads 2005-05-10T10:00:00Z + time-precision = h as @2005-05-10T10:00:00Z, so every hour- or minute-precision result fails against expectations such as @2005-05-10T10 or { @T10, @T11, @T12 }. The DateTimeExtractor already carried a TODO for this.

What

• value-type-extractor-utils.ts: declaredTimePrecision(element) reads the extension from a primitive's companion element; applyDeclaredTimePrecision(value, element) drops the components padded beyond the declared precision (h → hh, min → hh:mm, s → hh:mm:ss, ms → unchanged). Values without the extension, with a code outside h/min/s/ms, or without a time-of-day are returned unchanged, and any timezone offset is kept as sent. Nothing changes for engines that do not send the extension.
• DateTimeExtractor, TimeExtractor and DateTimeIntervalExtractor apply it to valueDateTime/_valueDateTime, valueTime/_valueTime and valuePeriod.start|end / _start|_end.
• Unit tests for each extractor (hour, minute, second, millisecond, unknown code, date-only value, list of times, Period boundaries incl. Interval<System.Time>), and a README paragraph next to the existing quantity-precision note.

Effect on cql-tests against a conformant engine

• CqlIntervalOperatorsTest / Expand / ExpandPerHour* (4 cases) go from fail to pass: @T10:00:00 is now read as @T10.
• The hour/minute-precision DateTime cases (DateTimeAdd5Hours, DateTimeHour, ToDateTime2, …) now extract as @2005-05-10T10Z instead of @2005-05-10T10:00:00Z. They still differ from the offset-less expectations, which is the separate timezone-offset-policy topic tracked in Functionality to support testing of Time zone offset  #119 and Wrong Expected Outcome for ToString of DateTime with No Offset Specified cql-tests#73 / Test Runner Not Detecting Equal Concept Values #81; this PR is orthogonal to that work and does not touch offsets.

Verification

npx vitest run test/: 235 passed (224 before). tsc --noEmit clean. Prettier clean on the touched src/ and test/ files (README.md already fails prettier --check on main, unchanged here).

🤖 Generated with Claude Code

https://claude.ai/code/session_01HrgCec45seYogQkmqRpSUi

---

Generated by Claude Code