[virtitnerd]

Depends on: #251, #254

Depends on:

• the last-known state PR (the robot's reported version is recorded in that store)
• the firmware check PR (the cloud answers the update information)

The branch merges both, so until they land the diff also shows their commits. The three new commits are
Install firmware from the official app's Update button, Show the firmware version a robot reports itself and
Document firmware updates and the [ota] setting.

Why

A robot paired to the local server never talks to Roborock's cloud, so it never learns about new firmware and the
official app cannot install it. Keeping a robot out of the cloud should not mean never updating it. People in #158,
#150 and #36 describe updating before moving to the local server for this reason.

What

Off by default: [ota] enable_install = true or ROBOROCK_SERVER_OTA_ENABLE_INSTALL=true (the variable wins).

With it on, the Update button (POST /ota/device/<duid>/upgrade):

1. asks the cloud for the offered version and the package address (/user/devices/<duid>/fw?version=...; the file
   name carries the MD5);
2. downloads the package to the data volume, checks the MD5, and serves it to the robot from a one-time URL;
3. refuses unless the robot is docked (or asleep on its charger), idle, not cleaning, error free and at 80% battery
   or more, with no other install running;
4. sends the robot's own OTA command (miIO.ota, download and install) and follows it through the reboot.

Two things that were not obvious and are handled:

• The robot's downloader only accepts capitalised header names (Content-Length). Starlette lowercases them, so
  packages are served with the names kept as written.
• The cloud answers the app's status poll with an error when it knows of no update. The official app reads an error
  from that poll as a failed update, and polls it whenever the robot is silent for 90 seconds, which the reboot
  causes. While an install runs the server answers that poll itself from the robot's real state (and IDLE, which
  the app reads as success, only after the robot is back).

The robot also reports its version (protocol 203) on every connect. The server keeps it and uses it for the update
check and the device list, because the cloud never learns the new version and would keep offering the same update.

Testing

Unit tests for each part, 550 passed in total. On hardware, a Qrevo Curv 2 Flow went from 02.33.48 to 02.35.52 through
the iOS app's Update button: 283 MB downloaded in 1m24s, installed in 2m15s, offline for 52s, and the robot reported
02.35.52 when it reconnected. The app showed success. An earlier install of a Qrevo Pro's current package confirmed
the delivery path.

Not included

The development tools used to find this (an admin dry run of the robot's OTA command and a cloud path explorer) are
not part of this PR. They are described in docs/firmware_updates.md.

Security

Installs are opt-in. Only the version the cloud offers can be installed, and the package is checked against the MD5
in the address the cloud returns. The robot verifies the firmware's signature itself. The latest-stable call stays
refused.

Related

#158, #150, #36 (context). There is no open issue for firmware updates; happy to open one if you prefer.