Challenge 2: Spot the Date-as-String Bug — Possible Solution
====================================================================

LIKELY ROOT CAUSE
------------------------------
The placedAt field is almost certainly stored as a STRING rather than
a real BSON Date value, and the query { $gt: "2026-02-01" } is
therefore comparing strings LEXICOGRAPHICALLY (character by
character, like comparing words alphabetically) instead of comparing
actual points in time.

WHY THIS EXPLAINS BOTH SYMPTOMS
------------------------------------
- Returning SOME January orders: if any January dates happen to be
  formatted in a way that sorts lexicographically AFTER "2026-02-01"
  (for example, inconsistent formatting, extra characters, or a
  different string layout for some records), they'll incorrectly
  satisfy the string comparison even though they're chronologically
  BEFORE February 1st.
- MISSING some March orders: conversely, some March dates might sort
  lexicographically BEFORE "2026-02-01" if their string
  representation differs even slightly (e.g. a different length, a
  stray extra character, inconsistent zero-padding), causing them to
  be incorrectly excluded even though they're chronologically well
  AFTER February 1st.

Both symptoms point to the same underlying cause: string comparison
doesn't understand "before" and "after" in a calendar sense at all —
it only understands character-by-character ordering, which happens
to often coincide with chronological order for perfectly consistent
YYYY-MM-DD strings, but breaks the moment there's ANY inconsistency
in how the dates were originally stored.

THE FIX
------------------------------
Store placedAt as a real Date value (e.g. using ISODate(...) or the
driver's native Date object) instead of a string, and query it with
an actual Date value: { placedAt: { $gt: ISODate("2026-02-01") } }.
Real Date comparisons compare actual points in time, immune to this
entire class of formatting-dependent bug.