Exercise 1: Signing In With the Legacy Hash — Possible Solution
====================================================================

SETUP
------------------------------
Per this chapter, the Admin model is added to schema.prisma and
migrated, then seeded with a real row whose passwordHash is the actual
legacy PHP-generated bcrypt hash (a string starting with $2y$) - copied
in as-is, not regenerated. auth.ts is configured with the Credentials
provider's authorize() function calling bcrypt.compare(), and the
app/api/auth/[...nextauth]/route.ts handler is wired up to expose the
NextAuth API routes.

SIGNING IN
------------------------------
Submitting the correct plaintext password (the one that originally
produced the legacy $2y$ hash) through the sign-in flow calls
authorize() with that plaintext password and the stored admin's email.
bcrypt.compare(plaintextPassword, admin.passwordHash) returns true, so
authorize() returns a real user object rather than null, and NextAuth
establishes a session.

WHY NO SPECIAL CONFIGURATION WAS NEEDED
------------------------------
bcryptjs's own compare() function reads the algorithm version, cost
factor, and salt directly out of the hash string itself - the $2y$
prefix and the fields that follow it - rather than requiring the
caller to specify them separately. Because bcrypt's hash format is
standardized enough across implementations, the JavaScript library
correctly parses and verifies a hash that PHP's own password_hash()
originally generated, with nothing hash-format-specific set anywhere in
this chapter's own code.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly uses the real legacy hash rather than a freshly-generated
one (which would defeat the whole point of the exercise), and correctly
explains why bcryptjs needs no special configuration - because the hash
string itself is self-describing - rather than just asserting
compatibility without explaining the mechanism.