GET /recipes needs pagination

GET /recipes currently returns every single recipe row, every time, with every ingredient and step nested in -- no limit. That's fine with a handful of seed recipes; it's a real problem the day this product has real content. A recipe site with 50,000 recipes turns every GET /recipes call into a multi-megabyte response with joined ingredient/step data for rows the client will never render. That's slow responses, wasted bandwidth (worse for anyone on mobile data), and unnecessary load on the database and API process for a page that only ever shows the user 20-50 recipes at a time. This is the single highest-leverage change for keeping the API fast as the content library grows, and it's the kind of thing that's cheap to add now and increasingly disruptive to retrofit later (client code that assumed a bare array has to change no matter when this lands).

GET /recipes (src/routes/recipes.js) accepts ?maxCookingTime=N but has no concept of page or pageSize. It always runs a single prisma.recipe.findMany({ where, include, orderBy }) over the entire matching result set and returns it as a bare JSON array.

cd nodejs/recipe_api npm run dev # or: docker compose up

curl "http://localhost:3001/recipes?page=1&pageSize=2"

-> 200 [ { "id": 1, ... }, { "id": 2, ... }, { "id": 3, ... } ]

a bare array of EVERY matching recipe -- page/pageSize are silently ignored,

and there is no meta.total/meta.totalPages anywhere in the response

This touches the same where/include/orderBy query object as the existing maxCookingTime filter, so it needs to compose with it rather than replace it -- pagination and filtering are independent axes (you can imagine GET /recipes?maxCookingTime=30&page=2&pageSize=10) and the implementation should treat them that way. Getting total right requires either a second prisma.recipe.count({ where }) call using the same where clause as the paginated findMany, or an equivalent way of counting the full filtered set -- get this wrong and total/totalPages silently drift from what maxCookingTime actually filtered.

Look at how maxCookingTime is parsed and validated in the GET / handler -- that's the pattern to follow for page/pageSize (parse, validate, throw ValidationError on bad input). Prisma's findMany takes skip/take options for pagination; think about how page/pageSize translate into skip/take. For total, look at what other read methods prisma.recipe exposes for counting rows without fetching them.