Prevent duplicate note titles, safely under concurrent requests

POST /notes has no uniqueness check on title at all. Two, or two hundred, notes can share the exact same title (even the exact same case) with no error. There's also no protection at the database level -- Note.title has no unique constraint. This is the one ticket in this set that's genuinely about correctness under concurrency, not just correctness for a single request in isolation: a slow UI where a user double-clicks "Save," or two automated scripts racing to create a scheduled note, both need to end up with exactly one note, not two.

POST /notes accepts any number of notes sharing the exact same title, with no case-insensitive (or case-sensitive) uniqueness check anywhere in the request path, and no unique constraint at the database level to fall back on.

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":"Weekly Report","content":"v1"}' curl -s -X POST http://127.0.0.1:8000/notes -H "Content-Type: application/json"
-d '{"title":"weekly report","content":"v2"}'

-> both return 201 -- no uniqueness check exists at all, case-insensitive or otherwise

It's tempting to implement this as: "query for a note with this title; if none exists, insert." That's straightforward, reads clearly, and is wrong under concurrency: two requests can both run the SELECT and both see "no existing match" before either one commits its INSERT -- both then insert, and you're back to duplicates, just less often (only under contention, which makes it far worse in production than in casual manual testing). A check-then-act pattern like this is a textbook TOCTOU (time-of-check to time-of-use) race condition -- which is exactly why this ticket's test wraps genuinely concurrent requests in a 15-second timeout and uses a file-backed (not in-memory) SQLite database, so real, separate connections actually race each other instead of the race being masked by shared in-process state.

Think about what actually guarantees uniqueness under concurrent writers in a relational database: it's the database's own unique constraint (and the transaction/locking machinery behind it), not anything checked in application code beforehand. Look at how Note is defined in app/models.py -- a unique=True (or an explicit UniqueConstraint) on the right column enforces this at the database level regardless of how many concurrent requests are in flight. From there, create_note needs to handle the case where the database rejects the insert (SQLAlchemy raises IntegrityError on a unique constraint violation) and translate that into a 409 HTTP response, instead of letting a 500 leak out. Also think about case-insensitivity: a plain unique constraint on title as-stored would treat "Report" and "report" as different values -- the uniqueness check itself needs to be case-insensitive.