eRoT self-update

[chrysh]

The eRoT's own firmware update is not covered by any issue yet — #17 names "RoT (self-update)" as a bullet, but all existing design work (trial-boot capabilities, orchestrator effects, commit gating) is downstream-device-oriented. Self-update is one of SlotControl's two intended implementors (the other being interposed flash, see upstream PR OpenPRoT#392), and it raises questions the downstream flow doesn't answer:

• Who observes our trial boot? For downstream devices the eRoT watches a boot-complete line. For ourselves, the freshly booted trial image must prove its own health, and a hardware watchdog (not software) must force the fallback if it hangs — one-shot arming in the boot ROM / boot-select register so a failed trial automatically reboots the committed slot.
• Who commits? Downstream commits use the two-party gate: BMC requests, eRoT executes after boot confirmation. Does the same gate apply to our own image, and what confirms "healthy" — self-attestation, successful chain-of-trust walk over all downstream devices, or both?
• Rollback and recovery: what plays the role of golden image for the eRoT itself, and how does self-rollback interact with in-flight downstream state (a half-done downstream update must be restartable from scratch after an eRoT reboot — established assumption, everything is retested).
• Anti-rollback: the eRoT's own SVN floor advance (relates to Update anti-rollback params #18) must be gated on the confirmed boot of the new image, same principle as downstream.

Related: #17, #15 (active partition tracking), #18 (anti-rollback params); upstream OpenPRoT#377 (capability traits), OpenPRoT#383 (crash-loop handling), OpenPRoT#392 (SlotControl with one-shot arming).