Exercise 2: Why the Fix Lives in the Migration, Not the Query — Possible Solution
====================================================================

WHY IT'S NOT A QUERY-CODE FIX
------------------------------
Case-insensitive comparison on SQLite for contains, startsWith,
endsWith, and equals all come from the column's own COLLATE setting -
a property of how the column itself is defined in the database, not a
parameter passed into any individual query. There's no per-query
option available on SQLite (unlike mode: "insensitive" on other
providers) that could make one specific findMany() call behave
case-insensitively while leaving the column's own comparison behavior
unchanged.

WHY IT'S NOT A PLAIN schema.prisma CHANGE EITHER
------------------------------
Editing schema.prisma alone never changes the database on its own -
Chapter 2 already established that a real migration always has to run
before any schema change takes effect. On top of that, SQLite doesn't
allow a column's collation to be altered directly the way some other
databases do; the only supported route is recreating the table with
the column declared the way it's needed from the start. Since name
already exists as a real column from Chapter 2's own original
migration, changing its collation means generating a fresh migration
and hand-editing it to perform that table-recreation - which is exactly
why --create-only is used here, to stop Prisma from applying the
migration automatically before the SQL can be adjusted by hand.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies that case sensitivity is a column-level,
database-level property on SQLite rather than a per-query setting, and
it correctly explains why an existing column specifically requires the
generate-then-hand-edit-then-apply workflow, rather than treating this
as an arbitrary extra step.