maxCookingTime filter wrongly excludes recipes at the exact limit

A user browsing "recipes I can make in 30 minutes or less" silently loses every recipe that takes exactly 30 minutes. There's no error, no crash -- the recipe just never shows up. For a recipe discovery product, that's a content-visibility bug: recipes with suspiciously round cooking times (15, 20, 30, 45, 60 minutes -- exactly the numbers people are most likely to search for) are the ones most likely to vanish from filtered results. It under-serves recipe authors (their recipe is invisible under the filter a user would most naturally reach for) and quietly shrinks search results with no way for a user to tell whether the filter is working correctly.

GET /recipes?maxCookingTime=30 is documented (README.md's endpoint table and curl walkthrough) and generally understood to mean "recipes that take at most 30 minutes." In practice, a recipe with cookingTimeMinutes: 30 is excluded from that result set -- only recipes strictly under 30 minutes come back.

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

curl -X POST http://localhost:3001/recipes -H "Content-Type: application/json" -d '{ "title": "Exactly Thirty", "cookingTimeMinutes": 30, "servings": 2, "ingredients": [{"name": "Rice", "quantity": 200, "unit": "g"}], "steps": [{"stepNumber": 1, "instruction": "Cook the rice."}] }'

-> 201, note the returned "id"

curl "http://localhost:3001/recipes?maxCookingTime=30"

-> 200 [] -- "Exactly Thirty" is missing, even though 30 <= 30

This is the kind of boundary bug that unit tests miss unless they specifically probe the edge: any test that filters with a threshold comfortably above or below the data (e.g. maxCookingTime=30 against a 25-minute recipe) will pass whether the comparison is lt or lte. The existing suite (tests/recipes.test.js, its GET /recipes?maxCookingTime=N block) does exactly that -- it never asserts the exact-match case, so it stays green despite this bug. A green suite only proves what it actually asserts.

Look at the where.cookingTimeMinutes clause built inside the GET / handler in src/routes/recipes.js, right after the maxCookingTime query-param validation. Compare it against how "at most N" should read as a Prisma comparison operator, and against the sibling PATCH .../scale route in the same file, which has no such off-by-one. There's exactly one character-level operator to fix.