Capture expected error logs in negative-path builder API tests

[prestoncabe]

Summary

Running devbox run test prints alarming ERROR stack traces even when all tests pass. These come from builder-api negative-path tests that intentionally simulate failures and then assert that the resource handles them correctly.

Examples from EligibilityCheckResourceTest include:

• publishFailsWhenPublishedVersionsCannotBeRead, which simulates firestore unavailable
• createCustomCheckRemovesTheCheckWhenItsDmnCannotBeStored, which simulates storage unavailable

The production Log.error(..., exception) calls are appropriate and should remain error-level logs. The test harness should capture and, ideally, assert the expected log events so their stack traces do not spill into otherwise successful test output.

Why this matters

Successful test runs currently look like they contain failures, making real unexpected errors harder to notice and reducing confidence in the output.

Acceptance criteria

• Expected error logs from intentional negative-path tests are captured instead of printed in normal successful test output.
• The affected tests assert the expected error log where practical.
• Production error logging behavior and severity are unchanged.
• Unexpected errors remain visible and still fail tests where appropriate.
• devbox run test passes with cleaner output.