Exercise 3: Why the Explicit Date Check Still Belongs Here — Possible Solution
====================================================================

WHAT PRISMA'S OWN TYPE SYSTEM ACTUALLY CATCHES
------------------------------
If a genuinely malformed value were passed into the expiryDate field of
a create() call, Prisma Client's own validation would reject it with a
real error before any query even reaches the database - it does not
silently accept whatever text happens to be sitting in req.body the way
a raw SQL TEXT column would.

WHY THE EXPLICIT CHECK STILL BELONGS IN THE ROUTE
------------------------------
Prisma's own validation error is not designed to be a clean, user-facing
API response - it has no meaningful HTTP status code attached to it and
no message written for an end user or a frontend developer to read. If
that error were left uncaught, it would most likely surface as an
unhandled exception and a generic 500 response, telling the client
nothing useful about what was actually wrong with their request. The
explicit isNaN(Date.parse(expiryDate)) check exists to produce a clean,
specific 400 response with a real error message - the same kind of
response the "name is required" check produces - before Prisma's own
query layer is ever involved.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly acknowledges that Prisma does add a real backstop against
malformed data, while also correctly explaining why that backstop isn't
a substitute for explicit, application-level validation - the two serve
different purposes, one preventing bad data from reaching the database,
the other producing a genuinely useful response for the client.