feat(fw): answer /f/c rrcheck with a locally-forged access grant (#120)

[Lash-L]

Problem

Fixes #120. On (at least) the Qrevo Edge 2 (a298), the vacuum works for ~48 h after onboarding and then every RPC comes back as -10002 "rrcheck access denied" while MQTT stays connected. Re-onboarding restores control for another ~48 h.

Root cause

The firmware periodically calls POST /f/c to renew a local rrcheck access grant (at onboarding, daily, and an extra call exactly ~48 h after onboarding — see @novinc's request-level timeline in the issue). We had no route for /f/c, so it fell through to the generic catchall, which returns:

{"ok": true, "route": "/f/c"}

That is not a valid grant. The firmware scores every check as failed, tolerates the failures during a ~48 h grace window, then flips its RPC AccessControl state to denied. That is the -10002. Re-onboarding only resets the grace window, which is exactly the observed behaviour. This matches the RRCheck logic reconstructed from the S7-family AppProxy (48 h = the built-in 172800s default).

Fix

Add an /f/c route that forges an accepted grant locally, so the robot never has to contact the Roborock cloud. The response contract (from S7 firmware) is:

{ "k": base64(RSA-OAEP-SHA1(device_pubkey, aes128_key)),
  "d": base64(AES-128-ECB(pkcs7({"f":"t","c":<country>,"t":<unix>}))) }

• f == "t" is the accepted flag; t must be within ±300 s of the device clock (the robot syncs its clock from our /time/now).
• k is unwrapped by the device with the same RSA private key it uses for /region, so the public key the server already recovers during onboarding is exactly what we need. No Roborock key is involved.

That the device onboards through this server at all proves the recovered pubkey is correct and that the device uses this same RSA-OAEP-SHA1 wrapping for its bootstrap — the same wrapping /f/c's k field relies on.

Why this is safe to enable by default

The {k,d} / {f,c,t} shape and the absence of a response signature are verified only on S7 firmware. If a newer model (e.g. a298) expects a different shape or checks a signature, the device simply treats our response as another failed check — identical to the previous catchall behaviour — so this cannot regress a device that works today. If we have no recovered key for the device, we fall back to the catchall.

Changes

• shared/bootstrap_crypto: expose BootstrapEncryptor.get_pubkey
• shared/context: add ServerContext.device_public_key
• https_server: new fw_check route registered just ahead of the catchall
• tests/test_fw_check.py: play the device — build a keypair, register the modulus the way onboarding recovery does, drive the request through resolve_route, decrypt the grant, and assert f == "t"; also covers path variants and the no-key fallback

Testing

pytest -q → 291 passed locally (including the 3 new tests).

Note for testers

This needs verification on a real a298 beyond the 48 h mark with the robot fully offline. If it holds past ~48 h without re-onboarding, the fix is confirmed.