test coverage for database error handling

The error handling around the database is tricky but essential. The basics are:

• Certain errors correspond with very specific error codes and messages to end users about something in their control: a constraint violation is usually "name already exists", NotFound is usually a 404, etc.
• Transient failures (that is, failure modes that are likely a result of a failing component rather than bad input or a server bug) should get a 503.
• Non-transient server failures (i.e., bugs) should get a 500.

The difference between 500 and 503 communicates to clients whether they should retry, and it'll also be very helpful for us when supporting a broken system to quickly understand the nature of the problem.

In addition to all that: for all errors, we should test that we're maintaining the detailed message that comes from the database describing what happened. Having this in the logs can be the difference between root-causing a weird issue the first time we see it vs. having to iterate with the customer.

No files or tests are named in the issue. Start by locating the API's database error-handling entry points and existing error tests, then map constraint, NotFound, transient, and non-transient failures to the stated responses. Done means each case is covered and every error preserves the database's detailed message.