TinyRail v0.14.0-beta.12

La mise à jour par BLE ne se dispute plus la mémoire, et se libère seule

Deux défauts trouvés en diagnostiquant des mises à jour qui n'aboutissaient
pas. Tous deux touchent l'opération la plus critique du produit : une carte à
moitié écrite est le pire état possible.

⚠️ LE LIEN DISTANT S'EFFACE DEVANT UNE MISE À JOUR. Rien ne le suspendait, et
la session TLS du client MQTT fragmentait le heap : le plus gros bloc allouable
était tombé de 25 600 à 7 680 octets pendant qu'il tournait. Perdre le lien
distant deux minutes n'est rien à côté d'une mise à jour qui manque de mémoire.
Le client est DÉTRUIT, pas seulement arrêté, pour rendre la mémoire.
Mesuré après correction : 65 300 octets libres, plus gros bloc 55 296.

⚠️ UN TRANSFERT INTERROMPU SE LIBÈRE SEUL. Il ne se libérait qu'à la
DÉCONNEXION du client. Une application qui renonce sans se déconnecter — retour
arrière, passage en arrière-plan, plantage — laissait la carte occupée jusqu'au
redémarrage, et refusait toute nouvelle tentative. Au-delà d'une minute sans
paquet, le transfert est abandonné.

⚠️ Ce que ces corrections NE changent pas, parce que c'était déjà juste : une
image n'est activée qu'APRÈS vérification de son empreinte, un transfert
interrompu ne laisse rien d'actif, et le bootloader revient à l'ancienne image
si la nouvelle démarre mal (CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE). Une mise à
jour qui échoue laisse une carte qui fonctionne.

Vérifié de bout en bout : 1,53 Mio envoyés par BLE, empreinte vérifiée, bascule
de partition, redémarrage sur la nouvelle image.

35 vérifications natives sur le délai d'abandon, dont le débordement de
millis() à 49,7 jours et le cas inverse : un transfert qui reçoit régulièrement
ne doit jamais être coupé.