No way for a client to fetch its own profile (GET /auth/me)

POST /auth/login returns a user object at login time, but that's the only moment a client ever sees its own profile. If the token is loaded from storage later (page refresh, a different tab, a mobile app resuming from background) there is no endpoint to ask "who am I, according to this token?" without re-deriving it client-side from the JWT payload -- exactly the kind of trust-the-client shortcut this codebase's ownership model is built to avoid everywhere else.

A route has already been wired up -- GET /auth/me in src/routes/auth.js, behind requireAuth -- but its handler is only a stub that unconditionally throws Error('GET /auth/me is not implemented yet'), which the centralized error handler turns into a 500.

cd nodejs/blog_api node_modules/.bin/jest --config practice-tickets/jest.config.js
practice-tickets/tests/ticket03_get_auth_me_missing.test.js --verbose

GET /auth/me (with a valid token) returned 500 instead of 200.

requireAuth only decodes the JWT payload ({ sub, email }) into req.user -- it never re-reads the database, so a token's claims could in principle be stale and, more importantly, nothing anywhere currently proves the account still exists / fetches its createdAt. This is a one-route, one-query feature, but it's the first time a route needs to look up "the caller's own record" rather than someone else's, which is a slightly different shape than the ownership lookups already in this file.

Replace the stub body of GET /me in src/routes/auth.js. Look at how src/middleware/ownership.js's loadPost/loadComment do a plain prisma.<model>.findUnique({ where: { id } }), and how serializeUser from src/lib/serialize.js is already used by /register and /login -- this route needs the same two pieces, just keyed on req.user.id instead of a route param.