Improves OTA update reporting and process

[IDisposable]

Improves the OTA (Over-The-Air) update process by adding better reporting and handling of reboot requirements.

• More detailed logging, state management for reboots
• Adds a rebootNeeded and rebooting state to the OTA process.
• Implements UI changes to indicate reboot status and provide a reconnect button.

[IDisposable]

@adamshiervani Not actually sure how to go about testing this...

[adamshiervani]

In the Makefile, you just set a low number and run ./dev_deploy.sh -i. If you check for updates with that, you should be able to get through the OTA process.

I'll try that out now.

[adamshiervani]

The OTA mechanism technically works. I was able to upgrade a device by lowering the version number in the Makefile. The code cleanup and the more granular state pushes to the client are great, but I have a few usability and robustness concerns.

The updated UI is confusing (I suspect flex-col is missing 😄). Despite the copy, it’s not immediately clear whether the reboot is automatic or requires the user to click “Reboot,” and it’s not obvious what happens if a reboot is already pending. All valid UX questions from the user’s perspective.

OTA Component

With the current implementation, if the reboot + IP assignment takes longer than the WebSocket reconnect policy allows, the “Reconnect” and “Reboot” buttons can lead the client to stale, lazy-loaded settings routes that break the app.

Stale settings pages

This PR aside, the only actual problem I noticed with OTA is the client-side state becomes desynchronized after a reboot: the client doesn’t perform a full refresh when the update completes. This is likely not caused by insufficient OTA-status events, but rather, the WebSocket reconnect threshold is being exceeded during the reboot/IP-assignment cycle (for example, DHCP can take a while). You can actually reproduce this by pulling the Ethernet cable during reboot -- the client hits the reconnect timeout and stops trying.

I would simply suggest extending the WebSocket reconnect threshold during updates to infinity. This way, the only thing that I can think of that could break the client-side part of the OTA mechanism is if DHCP assigned a different IP to the JetKVM, but that's fine for now.