Exercise 2: Querying the Raw Array Instead of the Joined String — Possible Solution
====================================================================

WHAT HAPPENS
------------------------------
Changing the query to:

const page = await prisma.page.findUnique({ where: { fullPath: path } });

(passing the raw string[] array directly, instead of path.join('/'))
does not throw an error at build time or at request time. The request
simply falls through to the if (!page) branch and calls notFound() -
every single visit to every page on the site behaves as if nothing
exists, even for genuinely real, correctly stored pages.

WHY PRISMA DOESN'T RAISE A TYPE ERROR
------------------------------
Prisma's own generated types for a @unique String column expect a
string value for an equality lookup, and TypeScript would normally
catch passing a string[] where a string is expected - but this
specific mismatch is easy to miss if fullPath is typed loosely
somewhere upstream, or if the code was refactored without re-checking
the parameter type. Even where TypeScript does catch it, the resulting
error is a generic type-mismatch message, not anything mentioning
"array vs string" or "did you forget to join the path" - it doesn't
explain the actual mistake in a way a developer would necessarily
recognize immediately, especially since the code compiles fine if
fullPath's own type is ever widened to something looser like unknown
or any during a refactor.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies that the failure mode is silent (no runtime
crash, no page ever matches) rather than loud, and correctly explains
why this specific mistake is a real, easy trap rather than something
that would obviously and immediately announce itself - directly
justifying this chapter's own warning about the array-vs-string
difference from Astro's own single-string params.path.