fix: stop StatusUpdateTrigger from overriding user-configured StatusUpdater timeout

[herley-shaori]

Summary

Fixes #5147

Problem

StatusUpdateTrigger.updateStatus() unconditionally calls statusUpdater.timeout(intervalCheck.getInterval()) on every status check cycle. This overwrites any user-configured timeout on StatusUpdater with the status-check interval value (default 10s), making it impossible to customize the timeout — either via a custom bean definition (as documented) or through the spring.boot.admin.monitor.default-timeout property.

Evidence from the reporter: Setting a 30s timeout still results in TimeoutException at 9000ms (interval 10s minus the 1s margin applied by getTimeoutWithMargin()).

Root Cause

• StatusUpdater.timeout(Duration) is a mutable setter that modifies the instance's internal timeout field and returns this.
• StatusUpdateTrigger called it before every updateStatus() invocation, resetting the timeout to intervalCheck.getInterval() regardless of what was previously configured.
• This behavior is inconsistent with InfoUpdateTrigger, which calls infoUpdater.updateInfo() directly without overriding any timeout.

Changes

1. StatusUpdateTrigger.java — Removed the statusUpdater.timeout(intervalCheck.getInterval()) call. Now calls statusUpdater.updateStatus() directly, consistent with how InfoUpdateTrigger works.
2. AdminServerAutoConfiguration.java — Applied monitor.defaultTimeout from AdminServerProperties when constructing the auto-configured StatusUpdater bean, so the property spring.boot.admin.monitor.default-timeout is respected out of the box.
3. StatusUpdateTriggerTest.java — Removed the now-unnecessary timeout() mock setup.

Behavior After Fix

• Default case: StatusUpdater uses defaultTimeout from properties (default 10s) — no change in behavior.
• Custom bean: Users who define a custom StatusUpdater bean with a custom timeout will have that timeout honored, as documented.
• Property override: spring.boot.admin.monitor.default-timeout now correctly applies to status checks for the auto-configured bean.

Test Plan

• All 6 existing StatusUpdateTriggerTest tests pass
• Verify with a custom StatusUpdater bean that sets timeout to 30s — TimeoutException should report ~29s, not ~9s