driver: Settle the eRoT's last self-update at boot

[chrysh]

When the eRoT updates its own firmware, it has to reboot into the new image. Everything it knew in RAM is gone after that, so before the reboot it writes a note to durable storage saying which image it is trying and with which SVN. That note is the session.

The new image goes into the secondary slot and the session is marked pending, so the next reset runs that image once. That trial run is then either confirmed or reverted.

This PR adds settle_self_update, which runs at the start of the next boot. It reads the session plus one more fact, which image actually booted, and says what it found:

• No session: nothing happened, carry on.
• The session is pending and the trial image booted: this boot is the trial run. Nothing here judges it. The update agent does that with UpdateSecurityRevision, so the session is left alone.
• The session is prepared or pending but the confirmed image booted: the update never ran, or its trial failed and the platform fell back. The session is reverted, so the update is done again instead of counting as finished.
• A trial image is running that no session claims: the session is reverted, which also clears the pending mark, so the confirmed image runs after a reset. The eRoT must not keep running an image nothing vouched for.
• The session is confirmed and the floor is still below its SVN: the floor advance is what is left, and the update agent asks for it, so this boot does not do it.
• The session is confirmed and the floor already reads that SVN or higher: the advance landed before a crash, so the session is closed here.

The three answers are Settled, AwaitingUpdateAgent { svn } and UnclaimedImageRunning. Settled means nothing is left to do, so the boot carries on and a new self-update may start. AwaitingUpdateAgent means a session is still being judged, so no new self-update may start: recording one would overwrite the session.

Running it twice lands in the same place, which is what lets a boot that died partway through simply repeat it. A storage fault leaves the session as it is and fails secure rather than guessing, and the failure carries the session's or the floor's own error in a SettleError, which is what the core::error::Error bound on those seams is for.

It is a free function taking the session and the eRoT's own floor, not a board seam. Nothing calls it yet, and a capability joins BoardCapabilities when an executor needs it, so board.rs is untouched.

Not in this PR: the call site, turning the answer into a state machine event, and the 0x22 path that confirms and advances the floor. Those belong with the message plumbing, which this repo does not have yet.