Exercise 1: The Real Regression — Possible Solution
====================================================================

WHY "milk" WOULDN'T FIND "Milk"
------------------------------
Prisma's own documentation for the SQLite provider states directly that
text fields created by Prisma Client in SQLite databases do not support
case-insensitive filtering by default. The naive search route's
contains: q filter therefore performs an ordinary case-sensitive
substring match against whatever is actually stored in the name
column. Since "milk" and "Milk" are different strings once case is
taken into account, a case-sensitive comparison simply doesn't
consider them a match - this is the query behaving exactly as
documented, not a bug in the code itself.

WHY mode: "insensitive" DOESN'T FIX IT HERE
------------------------------
mode: "insensitive" is a real Prisma feature that does fix exactly this
problem - on PostgreSQL and MongoDB. It is not supported on the SQLite
provider at all. Adding it to a SQLite-backed query either has no
effect or produces an error, depending on the Prisma version - either
way, it does not restore case-insensitive matching on this database.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly cites Prisma's own documented default behavior for SQLite
rather than guessing at a plausible-sounding explanation, and it
correctly identifies that the obvious-looking fix (mode: "insensitive")
is specifically unavailable on this provider, rather than assuming
Prisma's options behave identically across every database it supports.