🔀 Reading: Pull Requests & Code Reviews

## Summary

Adds JWT-based authentication to the REST API. Previously all endpoints were publicly accessible.

## Changes

- Added `AuthMiddleware` class that validates Bearer tokens on protected routes
- Integrated with existing `UserService` to look up users by token claims
- Updated `/api/users` and `/api/orders` routes to require authentication
- Added `/api/auth/login` endpoint (POST) — returns a signed JWT on valid credentials
- Public endpoints (`/api/health`, `/api/docs`) remain unauthenticated

## How to Test

1. Start the server: `npm run dev`
2. Try accessing `GET /api/users` without a token → expect `401 Unauthorized`
3. POST to `/api/auth/login` with valid credentials → extract the JWT from response
4. Retry `GET /api/users` with `Authorization: Bearer <token>` header → expect `200 OK`
5. Test with expired token (set `JWT_EXPIRES_IN=1s` in .env and wait) → expect `401`

## Related Issues

Closes #312 — Security: unprotected API endpoints
Depends on #298 — UserService refactor (already merged)

## Summary

Adds JWT-based authentication to the REST API. Previously all endpoints were publicly accessible.

## Changes

- Added `AuthMiddleware` class that validates Bearer tokens on protected routes
- Integrated with existing `UserService` to look up users by token claims
- Updated `/api/users` and `/api/orders` routes to require authentication
- Added `/api/auth/login` endpoint (POST) — returns a signed JWT on valid credentials
- Public endpoints (`/api/health`, `/api/docs`) remain unauthenticated

## How to Test

1. Start the server: `npm run dev`
2. Try accessing `GET /api/users` without a token → expect `401 Unauthorized`
3. POST to `/api/auth/login` with valid credentials → extract the JWT from response
4. Retry `GET /api/users` with `Authorization: Bearer <token>` header → expect `200 OK`
5. Test with expired token (set `JWT_EXPIRES_IN=1s` in .env and wait) → expect `401`

## Related Issues

Closes #312 — Security: unprotected API endpoints
Depends on #298 — UserService refactor (already merged)

--- Comment 1 (from: sarah_dev) ---
nit: variable name `t` on line 47 should be more descriptive — maybe `token` or `authToken`?

--- Comment 2 (from: sarah_dev) ---
This looks correct, but could you add a comment explaining why we use RS256 
instead of HS256 here? It'll help future maintainers understand the design choice.

--- Comment 3 (from: marco_eng) ---
LGTM overall! One thing though — this will break the existing integration tests 
in `/tests/api/` since they don't include auth headers. These need to be updated 
before we can merge.

--- Comment 4 (from: sarah_dev) ---
Great work on the test cases — the expired token scenario is especially thorough. 
Really appreciate the attention to edge cases here.

--- Comment 5 (from: marco_eng) ---
The token refresh logic should be out of scope for this PR — let's track it in a 
separate issue to keep this focused. I'll create a ticket.