Fix auctioneer tests after bumping the retry interval

[mariash]

[ai-assisted=yes]

• Read the Contributing document.

Summary

Root cause: commit b387957 changed the auctioneer's lock retry interval from 1s (SQLRetryInterval) to 5s (RetryInterval). This collided with ginkgomon.Runner's hardcoded default StartCheckTimeout of exactly 5 seconds — auctioneer only logs "auctioneer.started" (the test's StartCheck string) after ifrit.Invoke() returns, which blocks until the lock is acquired. When the lock is initially unavailable, the test harness kills the process at t=5s in a race against auctioneer's own first retry attempt (also at t=5s), so the process never got a chance to succeed. This wasn't a hang — the process was being silently SIGKILL'd by the test harness itself, which is why no error or panic ever appeared in the logs.

Fix in auctioneer/cmd/auctioneer/main_test.go:

1. Set StartCheckTimeout: locket.RetryInterval + 5*time.Second on the ginkgomon runner so it survives at least one retry cycle.
2. Bumped the "acquires the lock and becomes active" test's own Eventually timeout (was a stale 2*time.Second from before the retry-interval change) to match.
3. Extended the "invalid locket address" test's timeout, since it turned out to implicitly depend on the old 5s StartCheckTimeout to produce its expected "process exits with error" — a malformed locket address doesn't actually cause a fast, explicit failure in auctioneer's code; it retries forever and previously only died via that timeout.

Backward Compatibility

Breaking Change? No