feat: Own WINC WiFi-flash prompt orchestration (wire WifiBridgeActivator + prompt-aware process-runner)

[tylerkron]

Problem

IExternalProcessRunner/ProcessExternalProcessRunner only spawn the WINC flash tool and stream output; ExternalProcessRequest.StandardInputResponseFactory is a plain Func<string,string?> with no way to express "on this stdout marker, run a device-side side-effect (LAN:FWUpdate+LAN:APPLY) to win the bridge-init race, wait N seconds, then reply", nor to retry on transient failure markers.

Core already ships WifiBridgeActivator (src/Daqifi.Core/Firmware/WifiBridgeActivator.cs) that performs exactly this serial bridge activation (DTR settle, FWUpdate/APPLY timing) — but FirmwareUpdateService.BuildWifiProcessRequest (:706-777) never invokes it. So daqifi-desktop reimplements all of it in WifiPromptDelayProcessRunner (208 LOC) as a decorator.

Proposed

1. Add a prompt-aware hook to IExternalProcessRunner (stdout marker -> async action + delay + reply, plus transient-failure retry).
2. Invoke WifiBridgeActivator from FirmwareUpdateService at the power-cycle prompt.

Evidence

• Desktop decorator: Daqifi.Desktop/Device/Firmware/WifiPromptDelayProcessRunner.cs:13-19,99-149; wiring FirmwareUpdateCoordinator.cs:390-427,449-452; race rationale SerialStreamingDevice.cs:269-278
• Core unused helper: WifiBridgeActivator.cs:1-82; not called by FirmwareUpdateService.cs:706-777

Related

• WiFi chip-info probe: kick LAN:APPLY before declaring ChipInfoUnavailable #203 (kick LAN:APPLY before declaring ChipInfoUnavailable) and Retry LAN chip-info probing during WiFi update startup #144 (retry LAN chip-info probing during WiFi update startup) — same WiFi-update-startup timing area.

Identified via a cross-repo audit to make daqifi-desktop a thin wrapper over Core.

[tylerkron]

Unblocks the corresponding daqifi-desktop cleanup: daqifi/daqifi-desktop#614 (which is Blocked by this issue).