Support date-only filter values on DateTime fields

[mshd]

react-admin date inputs emit YYYY-MM-DD, but Prisma requires strict ISO-8601 and
rejects date-only strings outright:

Invalid value for argument createdAt: premature end of input. Expected ISO-8601 DateTime

So any createdAt_gte / createdAt_lte filter coming from a date picker threw before
reaching the database. extractWhere now expands date-only values on the comparison
operators to a full timestamp at the correct day boundary.

Prisma has no built-in date-only comparison, and @db.Date doesn't help — it rejects
YYYY-MM-DD too (prisma#25455).
Constructing the boundaries manually is the documented workaround.

Boundaries

The boundary depends on inclusivity, not direction, so each operator keeps a distinct meaning:

filter	coerced value	matches
gte D	D T00:00:00.000Z	D onward, D included
lte D	D T23:59:59.999Z	up to D, D included
gt D	D T23:59:59.999Z	after D, D excluded
lt D	D T00:00:00.000Z	before D, D excluded

Coercion only fires on values matching ^\d{4}-\d{2}-\d{2}$. Full timestamps, numbers,
and every other operator (contains, equals, in, startsWith, …) pass through untouched.

Also fixed

Nested comparison filters were double-wrapped — { createdAt: { gte: "..." } } became
{ createdAt: { gte: { contains: "..." } } }. Nested gt/gte/lt/lte now resolve
correctly. Other nested operators (equals, contains, in) still have this bug;
left for a follow-up.

⚠️ Behavior change

_gt / _lt previously produced the same coerced value as _gte / _lte, making the
strict and non-strict operators indistinguishable. They now exclude the named day.
If an admin filter labelled "after" sends _gt and expects the date included, switch it
to _gte.

Known limitations

• Day boundaries are hardcoded to UTC; non-UTC users may see edge records off by a day.
• Coercion is schema-blind — a String column holding a date-shaped value
  (e.g. sku_gte: "2025-01-31") is also converted. A DMMF-based type check would fix this;
  tracked as a follow-up.

Tests

166 passing, including new cases for all four operators, nested filters, and non-date
values passing through unchanged.

Two notes: the nested double-wrap fix isn't in the branch's changeset yet — worth its own entry since it won't show up in the changelog otherwise. And before merging,
it's worth grepping the admin for existing _gt/_lt date filters, since those are the only ones whose behavior actually changes.

[ogroppo]

Hi mate, this is great idea! however I run into this desire before, and decided not to do this because you're assuming the timezone (UTC).
So the date should be "coerced" on the browser/client and sent up to the server with the offset.
So if you are in indonesia, and have a datepicker that sends up only the date, you gonna have quite a few results missing!