driver: Advance the eRoT's own floor when the update agent asks

[chrysh]

Rebased onto ocp-global-demo-wip now that #509 merged, and reshaped to match it: #509 landed as the free function settle_self_update, not a PlatformDriver method, so this is a free function too. One commit now, no stack note.

The counterpart to #509's hold. commit_self_svn_floor(session, floor) takes the SVN the confirmed session recorded, advances the eRoT's own floor, and closes the session. The caller runs it when the FD reports SvnCommitPending, then answers with perform_svn_commit on Ok or reject_svn_commit on Err. That is the settled policy: the floor never moves at activation, only when the update agent asks with UpdateSecurityRevision after a trial boot.

Refused unless the session is confirmed and still open, so a request with nothing behind it cannot move the floor: no image has proven itself at that SVN. Faults come back as CommitFloorError, carrying the session's or the floor's own error the way SettleError does.

Safe to repeat across the crash window between the advance and the close: advance is a no-op at or below the floor, so a request repeated after a crash finishes the close. Once the session is closed a repeat is refused, so an answer that never reached the update agent leaves its retry refused, with the floor already where it asked. Whether the caller should answer that retry with perform_svn_commit anyway is the same open question as a lost IPC response.

A floor that cannot take the SVN leaves the session open, so the next request tries again rather than losing the advance.

This completes the openprot half of decision 4 (hold at boot, advance on 0x22). The IPC ops already exist: SvnCommitPending, perform_svn_commit and reject_svn_commit in pldm/api and #510's client. What is still missing is on the pldm-lib side: the FdOps callback that turns a received UpdateSecurityRevision into that pending status. pldm-lib #22 landed the message itself.

Not here: the board wiring, and the event-loop glue that polls QueryStatus, sees SvnCommitPending and routes it here. Also not here: any check that the SVN the request names matches the session's. The session is authoritative and the request's SVN is ignored; if a mismatch should be rejected, that belongs in the FdOps callback.