Search silently requires a match in title AND content, not either

Search is the primary way a user with more than a handful of notes finds anything again. Right now, GET /notes?q=... only returns a note if the search term happens to appear in both the title and the content -- which real notes almost never satisfy (a title is a short label; content is the actual text). In practice this means search returns far fewer results than it should, or none at all, for completely reasonable queries. To a user this looks like their notes vanished. This is the kind of regression that generates "where did my note go?!" support tickets and makes people stop trusting the search box -- high priority even though the fix is small.

The README and the endpoint's own docstring both state that q matches (case-insensitively) against title or content substrings. The current query building does not implement "or" -- it applies two separate LIKE conditions to the same .filter() call, which SQLAlchemy (like plain SQL WHERE a AND b) combines with AND.

cd fastapi/notes_api source .venv/bin/activate uvicorn app.main:app --reload & curl -s -X POST http://127.0.0.1:8000/notes -H "Content-Type: application/json"
-d '{"title":"Paris trip","content":"pack sunscreen and passport"}' curl -s -X POST http://127.0.0.1:8000/notes -H "Content-Type: application/json"
-d '{"title":"Weekend errands","content":"pick up dry cleaning near Paris Ave"}' curl -s "http://127.0.0.1:8000/notes?q=paris"

-> [] -- both notes contain "paris" in exactly one field, so neither satisfies "title AND

content", even though both should match.

This is a list_notes query-construction bug, and it also happens to be already covered by two pre-existing tests in tests/test_notes.py (test_search_by_q_matches_title_and_content_case_insensitively and test_filter_by_tag_and_q_are_combinable), which currently fail because of it -- a good example of how the main suite is expected to catch some of these injected bugs on its own.

Look at how query.filter(...) is called for the q branch in app/crud.py::list_notes, versus how a single .filter() call combines multiple positional conditions by default. SQLAlchemy has an explicit construct for "at least one of these conditions" -- it's already imported and used elsewhere in this project for exactly this kind of OR condition.