Contact search only matches when the term is in name AND email AND phone

Search is one of the headline features in the README (?search= matches "substring on name/email/phone"). As shipped right now, a search only returns a contact if the search term appears in all three fields (name, email, and phone) at once. Since most contacts don't have a phone number, or have one that obviously doesn't contain letters from someone's name, this means search returns nothing for almost every real query. Any user relying on search to find a contact -- the single most common thing a contact-book user does -- gets empty results and assumes the person isn't in their contact list at all. This is a silent, severe regression: no error is raised, the API just returns [].

GET /api/contacts?search=<term> filters contacts using and_(name ilike, email ilike, phone ilike) -- the term must appear in all three columns simultaneously. A contact matching only by name (the overwhelmingly common case) is excluded.

with the dev server running (flask run) and an empty database:

curl -s -X POST http://127.0.0.1:5000/api/contacts
-H 'Content-Type: application/json'
-d '{"name":"Ada Lovelace","email":"algorithm.pioneer@example.com"}'

curl -s "http://127.0.0.1:5000/api/contacts?search=Ada"

-> []

Expected: [{"name": "Ada Lovelace", ...}]

This is a classic operator-flip mistake: or_(...) accidentally became and_(...), most likely during a refactor or a copy-paste from a different filter that legitimately needed AND semantics. It is a one-word diff that inverts the meaning of the entire filter and is easy to miss in review because the code still "reads fine" -- and_(a, b, c) is syntactically identical in shape to or_(a, b, c).

Look at the search handling inside list_contacts() in app/blueprints/contacts/routes.py. Think about what combining condition turns "match if ANY field contains the term" into SQL -- and compare that against which SQLAlchemy combinator is actually imported and used there.