Changes made for Pathfinder V5 PC's

There is a transient socket error catch on one machine that can't be explained. Turned it into a warning since it looks like it actually continues communication, but as an error it restarted Pathfinder.

Changes made for Pathfinder V5 PC's.

Flash Programming Reliability FoldbusEthernet_IO.cs (SendFlashCommand) - Added 3-retry logic for flash packet transmission. After sending a flash packet, if no response is received, it retries up to 3 times before failing. Also fixed reboot detection order so that a controller reboot during flash is detected before treating the timeout as a failure.

FoldbusEthernet_IO.cs (SendCommand) - Added ForceTemporaryStatusChange(true) after 10 consecutive failed retries so the UI reflects the offline state during communication loss.

FoldbusEthernet_IO.cs (ResetCommDevice) - Added UDP receive buffer flush to clear stale packets after a controller reboot.

FlashBlackBoxManager.cs (TryFlashBlackBox) - Restructured so the queue stays running during RetrieveBoardData (which needs communication). Flash programming pauses the queue, programs, then the finally block handles recovery.

FlashBlackBoxManager.cs (finally block) - Calls PrepareForBlackBoxReboot (resets comm device, flushes UDP buffer, sets isBlackBoxReset flag) and ResetEventProcessingForReboot (clears event queue, switches back to direct event delivery) before resuming the queue and restarting status polling.

FlashTool.cs - Fixed CS0103 build errors (slave lock packet ID mismatch).

Post-Flash / Post-Reboot Recovery MachineCommunicationManager.cs (PrepareForBlackBoxReboot) - New method that resets the comm device and sets isBlackBoxReset = true so the next status response triggers the power-up sequence.

ApplicationManager.cs (OnLoginSuccess) - Root cause fix. Event handler subscriptions (StatusChanged, Transition_OfflineEvent, etc.) were guarded by !StatusPollingActive. After flash recovery started polling in the finally block, this condition was false, so handlers were never subscribed and the UI never received status updates. Fix: always subscribe handlers; only conditionally start polling.

BaseCO.cs (ProcessResponseAndDateTime) - Reset _exceptionResponse = ExceptionResponse.NoError at the start of each response processing. Without this, a single LowLayerCommException permanently poisoned the singleton StatusRequestCO error state.

StatusRequestCO.cs (EventProcessingLoop) - Added try-catch around the loop body. Previously any unhandled exception killed the thread permanently, causing all subsequent status events to queue up and never be delivered.

StatusRequestCO.cs (ProcessEvent) - Changed from re-throwing exceptions to logging only (NLog + Raygun). This prevents a single bad event from killing the EventProcessingLoop thread.

StatusRequestCO.cs (StartEventProcessingThread) - Now checks IsAlive (not just null) and resets _eventThreadShouldStop = false before starting, so a dead thread can be properly restarted.

StatusRequestCO.cs (PublishEvents) - When switching from direct to threaded event delivery (on reaching Idle), now also calls StartEventProcessingThread() to ensure the thread is actually running.

StatusRequestCO.cs (ResetEventProcessingForReboot) - New method that clears the event queue and resets _processEventsInSeparateThread = false, matching fresh startup behavior for post-flash recovery.

PowerUpCommManager.cs (ResetCompletionStatus) - Added isUARTMismatched = false reset so a stale mismatch flag doesn't block reconfiguration after reboot.