fix(search): read an out-of-form year as a year, not an offset or local date

[ddeboer]

isoToUnixSeconds passed its argument straight to Date, which reads a year outside the plain four-digit form as something other than a year – and never as NaN, so nothing threw, no field was left absent, and the value sorted and filtered as another date entirely:

• -1100 is read as a bare UTC offset and lands around 1100 CE – eleven centuries and a sign out.
• 25000 is read as a legacy local-time date and lands a year early (+024999-12-31T23:00:00Z on a UTC+1 host), on a boundary that moves with the host’s timezone – so the same source value indexes differently in a UTC container than on a developer’s machine.

The codec now pads the year to the signed six digits ISO 8601 expects before parsing, for both eras. Fixing it inside the codec fixes both call sites at once – the projection on the way in and @lde/search-typesense’s query compiler on the way out – which is what matters here: patching only one end turns a hidden, self-consistent error into a BCE range filter that matches nothing. A plain four-digit year and an already-expanded one pass through unchanged, so the form the API itself emits still round-trips, and a longer digit run (epoch millis, say) is left alone rather than cut into a year.

Deep time is conformant data, not a corner case: SCHEMA-AP-NDE blesses years beyond four digits for schema:dateCreated (-38000), and says nothing about era.

Two follow-ups from review close the gaps around that fix:

• A whitespace-padded year defeated the expansion, in both directions. XSD collapses whitespace around a date literal, so a padded form is legal and reaches the codec verbatim – nothing applies the facet on the way in, and the GraphQL DateRange bound is a plain string. A leading space stopped the anchored match (" -1100" → 1100 CE again, the very bug this fixes); a trailing one survived it into the legacy parser ("-1100 " → a year early, host-timezone dependent). The codec trims first.
• A numeric date derive could store seconds no Date can represent. Only a string goes through the codec, so a derive computing its own seconds was never range-checked; stored, it made every later read at the surface throw where an unparseable string simply leaves the field absent. The projection now drops it, next to the existing NaN guard.

The representable window is Date’s own, ±271,821 years around 1970, and the docs now say so rather than promising deep time without a limit.

• packages/search/src/schema.ts – expand the year in isoToUnixSeconds, trimming first
• packages/search/src/project.ts – drop a numeric date derive outside the representable range
• packages/search/test/schema.test.ts – unpadded BCE, deep time, a five-digit CE year (asserted on the absolute instant, so a timezone-dependent parse fails the test), a fuller BCE date, the pass-through forms, BCE-before-CE ordering, whitespace padding, and the range edge
• packages/search/test/project.test.ts – an out-of-range numeric derive leaves the field absent
• packages/search-typesense/test/query-compiler.test.ts – an unpadded BCE range bound compiles to a non-inverted range
• packages/search/vite.config.ts – the branch-coverage ratchet
• docs/reference/search.md – how a date is stored, which year forms the codec accepts, and over which window
• docs/decisions/0019-type-a-filter-by-what-its-field-keys-on.md – say which pairs idOnly replaces, in this package’s own terms

Fix #725