Update signing: damaged key file reported clearly; replacement keys pinned in code; 0.2.0 update docs

[Matlan1]

Summary

Follow-ups to the new update signing scheme.

• A damaged signing-key file is reported clearly. A saved updates/trust.json that is not valid UTF-8 was not caught as a corrupt file, so localm update showed the generic bug-report screen, POST /api/update/apply returned a 500 and scripts/verify_release.py crashed. All three now refuse the update with the same "the saved update signing keys are corrupt" error naming the file (exit 2 "COULD NOT CHECK" for verify_release.py).
• Replacement keys and data directories. A replacement set of keys is saved in the data directory that applied the update, while the install is shared by every data directory that runs it. The trust used is the higher-numbered of the set pinned in localm/updater.py and the saved one, so once the installed code pins a replacement set, every data directory trusts it. Every release that carries a replacement set also pins that same set in its own code. SECURITY.md now states this guarantee precisely.
• verify_release.py finds the 0.3.0 signature envelope. With no --sig, it now looks for <zip>.envelope before <zip>.sig.
• Docs. SECURITY.md and the changelog no longer say 0.2.0 must install 0.3.0 fresh (0.2.0 updates to 0.3.0 as before), the changelog bullet about the old key staying pinned is removed, and the update proxy's comments and README describe the signature envelope. Proxy behaviour is unchanged.

🤖 Generated with Claude Code