Exercise 1: Why No Shadow Field Is Needed Here — Possible Solution
====================================================================

WHY THE FIREBASE SIBLING NEEDS nameLower
------------------------------
Firestore has no native case-insensitive substring search operator at all. To make searching work regardless of how the user capitalizes their query, Food Tracker (React + Firebase) has to maintain a second, lowercase-only copy of each item's name (nameLower), written alongside the real name on every insert, purely to make matching possible.

WHY THIS COURSE NEEDS NO EQUIVALENT
------------------------------
SQLite's LIKE operator is case-insensitive for ASCII text by default - comparing "Yogurt" against a search for "yog" matches correctly with no special handling required. The route simply runs WHERE name LIKE '%' || ? || '%' directly against the real name column, with no duplicated lowercase field, no extra write-time bookkeeping, and no risk of the shadow field ever drifting out of sync with the real value.

THE SPECIFIC SQLITE FEATURE RESPONSIBLE
------------------------------
SQLite's built-in LIKE operator's own case-insensitivity for ASCII characters is the specific feature responsible - a native database-level behavior, not something this course's own code implements.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains why Firestore's own lack of native case-insensitive search forces the nameLower workaround, and correctly names SQLite's own case-insensitive LIKE operator as the specific built-in feature that makes an equivalent shadow field unnecessary here.