fix(search): apply the date storage codec to a derived date, and export the codec

[ddeboer]

A date field is stored as Unix seconds. The projection applies that codec to a path-read value, but a derives return value was stored exactly as returned – so a derive handing back an ISO 8601 string wrote a string into a field the collection declares int64, silently.

• A derived date goes through the same storage codec a read one does. A derive states its value in the field’s own terms: an ISO 8601 string is converted, a derive that already computed seconds passes through untouched, and an unparseable string leaves the field absent – exactly as a derive returning undefined does. This makes derives consistent with paths, which is what the issue was really about.
• A derive returning NaN leaves the field absent too. A derive is the only route a NaN can reach a document by – the read route guards it in setNumber. Blessing a derive that computes stored seconds itself makes the case reachable (Date.parse(bad) / 1000), and NaN serializes as null, which an engine rejects for a numeric field. Both routes now drop it alike.
• isoToUnixSeconds / unixSecondsToIso are re-exported from the package root. They are the documented encoding of a declared field kind, so they belong next to defineSearchType and SearchField. A schema author reaching them only through @lde/search/adapter was importing from a layer whose contract is “for engine adapters” and whose every other export is irrelevant to them. They stay on /adapter too, for the query compiler and the GraphQL surface.

Also documents the derive return-value contract on SearchFieldBase.derive and the codec’s place on the authoring surface in docs/reference/search.md.

Fix #726