Ingredient search silently became case-sensitive

GET /recipes/search?ingredient=... is the primary way a user finds recipes by what's in their fridge -- "what can I make with chicken?" It's documented as case-insensitive (README.md's endpoint table says exactly that), and until recently it was. Now, any query whose capitalization doesn't happen to match how the ingredient was originally typed into the database returns zero results -- not an error, just an empty, unhelpful list. Since most real users type search terms in lowercase or Title Case without checking how any given recipe author capitalized "Chicken Breast" vs "chicken breast," this silently breaks the feature for the majority of real-world queries while looking, to an automated smoke test that happens to match case, like it still works fine.

GET /recipes/search?ingredient=CHICKEN does not match an ingredient stored as "chicken breast". Only an exact-case (or coincidentally-cased) substring match succeeds.

curl -X POST http://localhost:3001/recipes -H "Content-Type: application/json" -d '{ "title": "Chicken Stir Fry", "cookingTimeMinutes": 20, "servings": 4, "ingredients": [{"name": "chicken breast", "quantity": 500, "unit": "g"}], "steps": [{"stepNumber": 1, "instruction": "Cook it."}] }'

curl "http://localhost:3001/recipes/search?ingredient=CHICKEN"

Expected: 200 [ { "title": "Chicken Stir Fry", ... } ]

Actual: 200 []

This is a real regression pattern: the where clause inside the GET /search handler still filters on name, still uses contains -- it looks right on a casual read -- but the mode: 'insensitive' Prisma option that makes Postgres's contains case-fold is simply absent from the search handler's where clause. This is exactly the kind of change that passes a casual code read and only fails when you actually run a query with mismatched case, which is why a dedicated regression test matters here more than most.

Compare the where clause inside the GET /search handler in src/routes/recipes.js against the Prisma docs for case-insensitive string filtering on Postgres (the option name is one word, and it's a sibling key next to contains inside the same object). There's a single missing key to restore.