Retry LAN chip-info probing during WiFi update startup

[tylerkron]

Problem

FirmwareUpdateService.IsWifiFirmwareUpToDateAsync(...) currently makes a single GetLanChipInfoAsync(...) call when the device implements ILanChipInfoProvider.

That is fine in steady state, but right after a PIC32 firmware update the application can be up while the WiFi subsystem is still finishing startup. In desktop integration, the first chip-info query could fail even though the device became ready a few seconds later.

That behavior forced desktop to add its own bounded retry loop before deciding whether to skip the WiFi flash.

Current desktop workaround

daqifi-desktop now retries LAN chip-info queries a few times with startup delays before deciding whether the WiFi firmware is already current.

This avoids unnecessary multi-minute WiFi flashes, but the retry policy lives in the app rather than in Core where the WiFi-update decision is defined.

Desired improvement

Core should support a bounded retry/backoff policy for the LAN chip-info/version check that happens before WiFi flashing.

Possible approaches:

• built-in retry options for IsWifiFirmwareUpToDateAsync(...)
• a FirmwareUpdateServiceOptions setting for LAN chip-info retries/startup delay
• an overridable hook for callers to supply retry policy without reimplementing the whole decision path

Acceptance criteria

• transient post-reboot LAN chip-info failures should not immediately force a WiFi flash
• callers should be able to rely on Core to make the skip/flash decision robustly during startup transients
• retry behavior should be bounded and cancellation-aware