Identity key loading should not panic if the key is invalid or corrupted

Currently, the RoT firmware boot flow attempts to connect to a manufacturing station to get its identity key signed if it finds no identity key programmed. That's fine (though I am slightly concerned about what happens if a sector gets erased in the field).

However, if it boots and finds an identity key, but that key is rejected by the PUF, it currently panics with e.g. failed to get ed25519 seed or similar. This could happen in the field if the contents of flash are corrupted, or if the PUF has been incompletely re-enrolled.

A panic in the boot code is bad, because that's before the kernel even starts -- much less SPI comms. So a device that panics this early in boot must be RMA'd to become useful.

It would be better to somehow record that "key is corrupt" and still boot, but decline to do any operations involving our identity. We may need to think about how to field re-provision such a device if such a thing is even possible, but that's a separate issue.

Trace the RoT firmware boot flow from identity-key loading through PUF validation, noting where errors such as “failed to get ed25519 seed” become a panic. Determine how a corrupted or PUF-rejected key can allow boot while disabling identity operations, and verify that the device no longer panics before kernel or SPI communication starts.