CoreMem 0.16.1 — timestamp filters compare chronologically

Try to spot the bug: your memory has a message with timestamp 2024-01-01T23:00:00 — naive, no timezone. You recall with ts_after="2024-01-01T02:00:00+00:00". 23:00 is clearly after 02:00. CoreMem excluded the message.

String comparison. "23:…" lexically compares before "02:…+00:00" — the naive timestamp without its timezone lost the comparison before anyone computed anything. Chronologically wrong, lexically right, and invisible in a demo because in a demo your timestamps are all the same format. It’s a documented known limitation since 0.13.2, and a known limitation is just a bug with a note on it.

What 0.16.1 does:

• ts_after/ts_before now parse via ISO (tolerant of Z and date-only forms), normalize naive → UTC, and compare chronologically. Mixed formats stop lying.
• Unparseable values fall back to the legacy lexical comparison — because failing loud on garbage is better than failing silently on shaped-like-a-date garbage.
• Boundary semantics unchanged (both filters exclusive).
• The wheel now ships CHANGELOG.md — which is how we found this one in the first place, reading our own history.

The honest footnote: timestamp pushdown into the Chroma scan is still deferred. Pre-existing stores keep arbitrary timestamp formats, and you can’t push a range into the index until the storage side normalizes. The Python post-filter is now chronologically correct — storage-side normalization is the next release’s problem, and the known-limitation note gets updated rather than deleted, because that’s what we do around here.

0.16.0 taught the store to filter before it searches; this release taught the filters themselves to tell time. The whole series is the same move — trust nothing, verify everything, and publish the note when you can’t yet.