Challenge 2: Register the App — Possible Solution
====================================================================

# library/settings.py — BEFORE (catalog is not registered)

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
]

# library/settings.py — AFTER (catalog added)

INSTALLED_APPS = [
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
    "catalog",  # <-- our new app
]

WHAT VISIBLY FAILS IF THIS STEP IS SKIPPED
-------------------------------------------
1. Models are invisible to migrations. Adding a model to
   catalog/models.py and running:

       python manage.py makemigrations

   produces "No changes detected" — Django never even looked inside
   catalog/models.py, because it doesn't know catalog is part of the
   project.

2. The admin site won't show the app at all. Even if you write
   admin.py to register a model, nothing appears on
   http://127.0.0.1:8000/admin/ — an unregistered app's admin.py is
   never imported.

3. Django's template loader won't find templates inside
   catalog/templates/catalog/... if APP_DIRS is relied on for
   discovery — an app's template directory is only searched once the
   app is installed.

4. No error is thrown for any of this — it's not a crash, just a
   collection of "nothing happened" symptoms, which is exactly what
   makes it a confusing first bug for someone used to FastAPI, where
   simply importing a router module is enough to activate it.

WHY THIS WORKS
--------------
- INSTALLED_APPS is a plain Python list of "app labels" (usually the
  app's import path) — Django iterates this list at startup to decide
  which apps' models, admin registrations, template directories, and
  management commands to actually load.
- Unlike FastAPI, where including a router (`app.include_router(...)`) is
  itself the act of "turning on" that code, Django separates "the code
  exists on disk" from "Django is aware of it" — the second step is what
  INSTALLED_APPS provides, and it's easy to miss because `startapp`
  doesn't do it automatically.
- Adding the app as `"catalog"` (its Python import name) is standard for
  a simple, top-level app; larger projects sometimes register apps via
  their AppConfig class path (e.g. `"catalog.apps.CatalogConfig"`) for
  finer control, but the simple string form is the correct starting point.