Log PostgreSQL server failures as errors

[UllasSHR]

Description of Changes

Log failed PostgreSQL responses according to their HTTP status: 5xx responses now use error!, while 4xx responses continue to use warn!. This lets internal failures classified upstream as server errors remain visible at the appropriate log level.

Adds a regression test that passes representative 400 and 500 responses through response(), checks the emitted log level, and verifies that the original error text is still returned.

Addresses #5695.

Interaction with #5869

#5869 classifies SQL execution failures as 400 or 500 in the client API and does not modify the PostgreSQL adapter. This change consumes that HTTP classification at the PostgreSQL boundary. It can merge independently; #5869 would increase the SQL execution failures that reach the 5xx branch.

Error responses can already be logged both where they originate and again at the PostgreSQL boundary. This change only corrects the severity of the PostgreSQL log for 5xx responses.

API and ABI breaking changes

None.

Rollback safety impact

n/a

Expected complexity level and risk

1 - The behavior change is limited to PostgreSQL response logging.

Testing

• cargo test --locked --offline -p spacetimedb-pg --lib
• cargo fmt --check -p spacetimedb-pg

[CLAassistant]

All committers have signed the CLA.

[JasonAtClockwork]

Thanks for taking a crack at this @UllasSHR! This isn't quite the right fix though for the issue and let me explain.

With the audit of our error/warn I discovered we don't maintain enough detail through the call chain to properly identify the log level. By the time an error reaches response() here the client vs internal distinction is already lost.

My goal with the issues flagged with #5640 was to dig in deeper into the chain of events to feed enough detail to correctly label our log entries. Even DBError's variants are not enough as areas of the code may use it incorrectly.

One quick heads up the test uses log::set_logger(...).unwrap(), which sets the process-wide logger. That will panic the first time another test in this crate needs to install it's own logger. This test here is probably overkill as we don't typically test the logs in this way.

[UllasSHR]

Thanks for explaining I traced it further and found where the detail is lost: sql::execute::run() returns a DBError, then Host::exec_sql() maps every failure to warn! and 400 Bad Request.
I also looked through #5869 and understand why matching only the outer variants isn’t enough, since Plan and WithSql can wrap internal errors while Other can contain client-caused failures.
Would it be useful for me to rework this PR to carry a structured client/internal classification from the execution layer, or should this remain a follow-up to #5869? I also understand the problem with the process-wide logger test and won’t keep it in its current form.