[bryantaustin13]

The extractors that map FHIR.Range and FHIR.Period back to CQL intervals — the representation the
"Using CQL with FHIR" IG specifies for Interval in Conformance Requirement 4.3 — had four defects:

• DateTimeIntervalExtractor hardcoded highClosed: true, so a Period with no end extracted as
  {highClosed: true, high: null}. An absent boundary is unbounded and therefore open;
  NumericIntervalExtractor already treated it that way, so the two disagreed on the same shape.
• A null valuePeriod, a null valueRange, or a null Range boundary each threw a TypeError out of
  the extractor, which turns a test into an error rather than a comparison.
• A Range boundary carrying unit but no code lost its unit, silently reducing a dimensioned
  boundary to a unitless one.

Adds tests covering all seven interval point types the IG maps (Integer, Long, Decimal and Quantity
onto Range; Date, DateTime and Time onto Period) plus the boundary and null cases above.

One behaviour is pinned deliberately rather than changed: a Period carrying no cqf-cqlType is read
as Interval<DateTime>. The point type cannot be recovered in that case — a boundary of
2012-01-01T00:00:00-07:00 is indistinguishable from a DateTime interval starting at midnight — and
the IG states that a value without cqf-cqlType is the FHIR type. Inferring a Date would be a
guess, so the test asserts the mismatch instead, keeping the missing extension visible as a server
defect.

Rebased on main (#129 and #135)

This branch was opened before #129 and #135 merged, both of which rewrote
datetime-interval-extractor.ts. main has since been merged in and the resulting conflict
resolved so that all three changes survive:

From	Kept
#135	applyDeclaredTimePrecision on the _start / _end companion elements
#129	List<...> unwrapping in declaredPointType
this PR	early-return null guards and highClosed: high !== null

Taking either side of the conflict wholesale would have lost work — this branch's copy of the file
predated both merged PRs, so accepting it would have reverted time-precision support and lists of
temporal intervals. Each behaviour was re-checked individually after resolving:

• a Period with hour time-precision extracts as @T10 / @T12 (Honour the time-precision extension on dateTime, time and Period boundaries #135)
• List<Interval<System.Date>> still resolves to Date literals (Support numeric uncertainty ranges, lists of numeric intervals, and lists of temporal intervals #129)
• an absent end yields highClosed: false (this PR)
• null valuePeriod, null valueRange and a null boundary no longer throw (this PR)
• a Range boundary with unit but no code keeps its unit (this PR)

The effective diff against main is now this PR's own work only — two extractors and one new test
file.

Verification

• tsc --noEmit: no new errors. The two src/server/rest-routes.ts errors it reports are
  pre-existing on main (Express 5 types req.params.id as string | string[] under TypeScript
  7.0.2) and are untouched by this PR.
• Unit suite: 247 passing (235 on main, plus this PR's 12).
• Full cql-tests suite against the reference engine (HAPI FHIR 8.10.0 / CQF engine 4.1.0, $cql,
  CQL 1.5, Node 26): 1639 pass / 170 fail / 14 skip / 0 error — identical to main, with zero
  status changes across all 1823 records.

That last point is the important one for review: no test changes status on this engine. The four
defects fixed here need inputs this engine does not produce — it never returns a Period without an
end, never a null boundary, and always includes code on Range quantities. The fixes are
demonstrated by the unit tests rather than by the integration run, and the integration run's role is
to confirm the merge resolution introduced no regression.