Exercise 3: Adding nameLower After Real Data Already Exists — Possible Solution
====================================================================

WHY THIS CREATES A GENUINE PROBLEM
------------------------------
If nameLower is only added to the add-item write path after the app is already in production with real items stored, every document created before that change simply does not have a nameLower field at all - it was never written for those documents. Per Chapter 2's own lesson that Firestore models "no value" as the complete absence of a field rather than a null placeholder, this means any search query filtering on nameLower will never match those older documents, because the field they'd need to match against doesn't exist on them at all.

THE CONNECTION TO CHAPTER 2'S "ABSENCE, NOT NULL" LESSON
------------------------------
Chapter 2 explained that Firestore's schema-on-read model doesn't retroactively enforce a field onto documents that predate a schema decision - a field is either present because something explicitly wrote it, or it simply isn't there. Adding nameLower to the add-item flow only affects documents created after that change; it does nothing at all to documents that already existed beforehand.

THE ACTUAL FIX
------------------------------
A one-time backfill script that reads every existing document in the items collection, computes nameLower from that document's own name field, and writes the missing field back onto each one. Only after that backfill runs do all documents - old and new alike - actually have a nameLower field that search can rely on.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that pre-existing documents are missing nameLower entirely (not populated with an empty or null value), ties this directly back to Chapter 2's field-absence lesson rather than treating it as an unrelated bug, and correctly identifies a one-time backfill script as the actual fix required.