Remove old pages system

[marcoacierno]

We used to have a pages system. We no longer need it as everything is driven by our CMS now. Remove it.

[marcoacierno]

@claude work on it

[claude]

Claude finished @marcoacierno's task in 10m 34s —— View job • claude/issue-4813-20260818-1755 • Create PR ➔

---

Removed the old pages system

• Gather context: find all references to the pages app
• Remove backend pages Django app + api/pages GraphQL types/queries
• Remove the MenuLink.page FK (its only remaining consumer)
• Remove frontend usage of page in the header query
• Add a migration to clean up the leftover column/table
• Regenerate backend/schema.graphql
• Run backend checks (pytest, mypy, ruff)
• Run frontend checks (codegen, tsc, biome)
• Commit & push

What changed

Backend

• Deleted the pages app (models.py, admin.py, apps.py, factories, migrations) and dropped pages.apps.PagesConfig from INSTALLED_APPS.
• Deleted api/pages/ and removed PagesQuery from api/schema.py, which removes the pages(code:) and page(code:, slug:) root fields and the Page type from the schema.
• Removed MenuLink.page (cms/models.py) and the page: Page field on the MenuLink GraphQL type — this FK was the only remaining reference to the old model.
• Deleted demodata/pages.json and the now-invalid "page": null keys in demodata/cms.json.
• Regenerated backend/schema.graphql.

Frontend

• header.graphql selected page { slug } on every menu link, but header/index.tsx only ever passes links (with text/link) to NavBar — the value was fetched and never read, so the selection is gone. No component changes were needed.

A note on the migration

cms/migrations/0006_menu_menulink.py had ('pages', '0002_auto_20190914_1504') as a dependency and created menulink.page with to='pages.Page'. Once the pages app and its migrations are gone that reference is unresolvable, so 0006 had to stop declaring both. That keeps fresh databases correct but leaves the column and the pages_page table behind on already-migrated ones, so cms/0009_remove_menulink_page.py drops them at the database level only (no state change — makemigrations --check reports No changes detected).

I verified that cleanup SQL two ways: the full migration chain runs green on a fresh database, and running the three statements against a hand-recreated pre-removal shape (pages_page plus the page_id FK) drops both and is idempotent on a second run.

Checks

$ uv run pytest -n auto
1340 passed, 15 skipped, 3 xfailed in 104.88s (0:01:44)

$ uv run pytest -c pytest.ini /tmp/test_migcheck.py -s   # makemigrations --check --dry-run
No changes detected
1 passed in 0.96s

$ uv run pytest api/tests/schema/conference/test_menu.py --migrations --create-db
4 passed in 50.16s

$ npx @biomejs/biome check .
Checked 343 files in 502ms. No fixes applied.

$ npx tsc --noEmit        # clean, after pnpm codegen

uv run mypy . and uv tool run ruff@0.12.5 check both still fail, but identically to main — I re-ran both against a stashed tree to confirm. The pre-existing failures are 3 mypy errors (badge_scanner/models.py "Source file found twice", plus two import-untyped notes) and 1 ruff error (unused patch import in sponsors/tests/test_tasks.py). None are in files this change touches, and I left them alone.

• claude/issue-4813-20260818-1755