Concurrent creates of the same custom_slug can crash instead of returning a clean 409

Any two clients racing to claim the same custom slug at the same instant (a common pattern for anything gamified or scarce -- "claim your brand name before someone else does") no longer get the advertised, documented behavior ("a collision must return a clean 409, never a 500"). Instead, depending on timing, one or both requests can crash with a raw database error. A public API that occasionally 500s under concurrent load on a completely foreseeable, common case (two people wanting the same short name) erodes trust in the API and generates noisy, confusing error reports that don't point at "someone else already has this slug."

if custom_slug: existing = ShortURL.query.filter_by(slug=custom_slug).first(); if existing is not None: return 409 -- this is a check-then-act (TOCTOU) pattern with no safety net: between the SELECT that checks for an existing row and the later commit() that actually inserts the new one, there is no lock and no except IntegrityError around the commit.

1. pytest practice_tickets/tests/test_ticket_16_slug_creation_race.py -v (uses a threading.Barrier to force both requests past the existence check before either proceeds, reproducing the race deterministically).
2. Observe: the two responses are never exactly one 201 and one 409 -- one or both raise an uncaught IntegrityError/OperationalError instead.

This is the canonical "check-then-act" concurrency bug: correctness under concurrency requires either (a) making the check-and-insert atomic (rely on the database's own uniqueness constraint as the single source of truth, and treat a constraint violation as the expected "someone beat you to it" signal -- i.e. wrap the commit in try/except IntegrityError), or (b) taking an explicit lock before checking. Removing the except IntegrityError safety net that used to wrap this commit, while adding a separate, unsynchronized pre-check, is exactly how a previously-safe insert-and-catch pattern regresses into a real race.

Think about what actually prevents two inserts of the same slug from both succeeding: it's the database's UNIQUE constraint, not the SELECT check (which only reduces how often the race is hit, not whether it is possible). The fix should treat the constraint violation itself as the authoritative "this slug is taken" signal, and handle it gracefully at the point where the commit can fail -- rather than trying to prevent the race with a faster or better-timed check.