[top_darjeeling] ROM patching discussion

- [ ] Add examples to why the 2nd partition ROM is useful. For example, it is useful to separate soc specific power management / boot medium data path from the baseline ROM; it is useful to allow different flash layout interpretation based on integration
- [ ] If a patch revision is no longer desired for some reason (vulnerable / broken), we need some agreed upon mechanism to invalidate this patch.
- [ ] If there are multiple patches, we need some agreed upon mechanism on whether a failure of the highest revision patch means we should fail over to a lower revision, or that should not be possible at all.
- [ ] Discuss how the patched ROM's contents should be handled as part of cryptographic identity. Key manager today already supports the idea of "sealing" and "attestation" identities, we may need to extend further upon this idea.
- [ ] If the patch re-direct mechanism creates timing issues, we need to consider how we may split the paths such that patching latency does not impact the rest of the system.

Start by reviewing the five open design questions in the issue: partition-ROM use cases, patch invalidation, revision fallback, cryptographic identity, and patching latency. No files, tests, or entry points are named. Done means reaching agreement on the mechanisms and documenting the resulting ROM-patching design.

Written by the indexing model from the issue text.