Exercise 3: Confirming the Database-Level Constraint — Possible Solution
====================================================================

STEPS
------------------------------
1. Using a plain MySQL client (mysql CLI, a GUI tool, or a raw query
   with no Drizzle involved at all), find a page row that has at
   least one child pointing at it via parent_id.

2. Run a raw SQL statement directly against the database:

     DELETE FROM pages WHERE id = <that page's own id>;

3. MySQL itself refuses the statement with a foreign key constraint
   error (something like "Cannot delete or update a parent row: a
   foreign key constraint fails"), even though this DELETE never
   went through Drizzle, Node.js, or the Astro project at all.

WHY THIS CONFIRMS THE CONSTRAINT IS DATABASE-LEVEL
------------------------------
Per this chapter, if onDelete: 'restrict' were only enforced by
Drizzle's own application code, a raw SQL DELETE that bypasses
Drizzle entirely would succeed without any resistance. Because the
database itself refuses the operation independent of how it was
issued, this confirms the FOREIGN KEY ... ON DELETE RESTRICT clause
is a genuine schema-level constraint - the same guarantee Laravel's
own restrictOnDelete() provides, and a guarantee Rails' own
application-level dependent: :restrict_with_error could not offer
against a raw SQL delete like this one.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly describes a real test that bypasses the ORM entirely,
and correctly explains why the database's own refusal - rather than
an application-level check - proves the constraint operates at the
database layer.