Deleting an in-use category returns a raw 500

Categories that still have expenses pointing at them are protected from deletion at the database level (a foreign key constraint) -- that part still works. But the application is supposed to translate that DB-level rejection into a clean, actionable 409 Conflict ("category is still used by existing expenses"). Right now it doesn't recognize the error and falls through to a generic 500, which looks like the server crashed instead of telling the user exactly what to do (remove or reassign the expenses first). This is a support-ticket generator: users will report "the app is broken" for entirely expected, preventable behavior.

Repo.Delete checks the Postgres error code for a foreign-key violation using the wrong SQLSTATE -- it compares against unique_violation (23505) instead of foreign_key_violation (23503), so the in-use case is never actually recognized and falls through to a plain 500.

Create a private category, then create an expense against it. DELETE /categories/{id} for that category, with a valid token.

Expected: 409 "category is still used by existing expenses"

Actual: 500 internal server error

23503 (foreign key) and 23505 (unique) are both common Postgres constraint-violation codes and easy to mix up when writing this kind of error-mapping code from memory -- a single wrong constant, still compiles, still type-checks, only shows up when the specific constraint actually fires.

Compare the SQLSTATE string Repo.Delete checks for against the one Repo.Create/Repo.Update check a few lines above (they're handling a different constraint -- read the migration's comments on both indexes/constraints to see which code belongs to which check).