test(wallet): make TransferPreapproval failure test robust to validator timeout

[samsondav]

Make the "Failure to complete TransferPreapproval creation should be handled correctly" wallet test robust to a transient validator HTTP timeout that flakes the log assertion under CI load.

Flake

Observed on the wall-clock-time (0) job: https://github.com/canton-network/splice/actions/runs/27450544466 (job: https://github.com/canton-network/splice/actions/runs/27450544466/job/81436663390)

forEvery failed, because:
  at index 0, Incorrect log level WARN. Expected: ERROR.
  Message: Request to .../api/validator/v0/wallet/transfer-preapproval (POST) resulted in a timeout after 38 seconds.
  Remaining log entries:
  ## ERROR ... HttpCommandException: HTTP 503 Service Unavailable POST at '/api/validator/v0/wallet/transfer-preapproval' ... The server is taking too long to respond

The test pauses validator automation so createTransferPreapproval cannot complete. The intended outcome is an HTTP 429 once the server-side RetryFor.ClientCalls loop in HttpWalletHandler gives up (ABORTED -> TooManyRequests). Under load the validator's HTTP request timeout fired first: HttpErrorHandler.timeoutHandler logged a WARN "resulted in a timeout after 38 seconds" and returned 503 instead. The strict ordered assertion in assertThrowsAndLogsCommandFailures then matched the unexpected WARN entry at index 0 with errorMessage, which requires ERROR level, and failed.

Fix

Assert the failure via assertThrowsAndLogsUnorderedOptional[CommandFailure]: a required ERROR entry matching either "429 Too Many Requests" or "503 Service Unavailable", plus an optional WARN entry matching the server-side "resulted in a timeout". This keeps the requirement that a genuine failure is surfaced and logged as ERROR, while tolerating the transient timeout WARN/503 on a slow host. Mirrors the existing pattern in ScanIntegrationTest and SplitwellUpgradeIntegrationTest.

Observed on PR #5937's CI run. The fix is by inspection; the integration test was not run locally.

[moritzkiefer-da]

I believe this is already fixed in #5940. have you still encountered this issue after rebasing to include that change?

[samsondav]

Thanks Moritz — you're right. #5937 branched ~45 min before #5940 merged and wasn't rebased, so that run didn't include the retry-delay fix. I'll rebase onto main to pick up #5940 and confirm; assuming the flake is gone I'll close this in favor of #5940.