FirmwareUpdateService should wait for application readiness after PIC32 reconnect

[tylerkron]

Problem

FirmwareUpdateService currently treats PIC32 recovery as complete once WaitForSerialReconnectAsync(...) can reopen the serial transport and device.Connect() returns success.

In desktop integration, that was not sufficient. After a PIC32 flash, the USB CDC port could re-enumerate and open successfully before the application firmware was actually ready to answer protobuf status requests. The next steps then ran against a half-started device:

• LAN chip info queries failed
• WiFi bridge prep failed
• desktop had to keep retrying reconnects outside Core

The relevant reconnect path is:

• JumpToApplicationAndReconnectAsync(...)
• WaitForSerialReconnectAsync(...)

Current desktop workaround

daqifi-desktop had to harden its serial adapter so Connect() does not report success until the device has produced an initial protobuf status message, with bounded GetDeviceInfo retries during startup.

That fixed the branch, but it is application-specific glue around a Core firmware-update lifecycle.

Desired improvement

Core should expose a first-class notion of "application ready after reconnect", rather than only "serial port reopened".

Possible approaches:

• extend the reconnect contract so callers can provide a readiness probe
• add an optional post-connect validation callback to FirmwareUpdateService
• provide a richer streaming-device interface for firmware update flows that can distinguish transport connected from app ready

Acceptance criteria

• PIC32 firmware update should not proceed past reconnect until the device is ready for normal application commands
• downstream callers should not need to implement their own status-wait loop just to make firmware update reliable
• the solution should remain transport-agnostic where possible