[chrysh]

Builds on #565, merged into ocp-global-demo-wip.

Issue: 9elements#18

An eRoT-held anti-rollback floor moved on Event::BootConfirmed, the moment
the orchestrator decided the updated image was healthy. That floor belongs to a
component that tracks no SVN of its own, and the agent commands the advance
with UpdateSecurityRevision (PLDM 0x22), so moving on the boot would burn
anti-rollback before the agent asked for it.

Event::SvnCommitRequest(id) is that request arriving. The floor it names is
one the eRoT holds, so there is no device-side commit to wait for; what gates
the advance is the window BootConfirmed opened. BootConfirmed now closes the commit-or-lock window and records the
component in awaiting_floor_advance; the matching SvnCommitRequest emits
CommitSvnFloor and clears it. An ask for a component with nothing
outstanding is dropped, so the floor takes the SVN once however many times
the agent asks.

Two design calls worth ratifying in review, both mirroring what the eRoT's own
session does rather than what the old BootConfirmed path did:

No watchdog bounds the wait. An agent that never sends UpdateSecurityRevision
leaves the floor where it is, the way a confirmed self-update session sits at
AwaitingFloorAdvance. Locking the platform because a remote agent went quiet
costs more than losing anti-rollback coverage for one image. CommitTimeout
still guards pending_commit alone, so commit-or-lock stays "the device has
to boot".

An outstanding advance is voided by anything that puts the running image under
suspicion: entry to Updating or Recovering, and gating the component out of
service. The SVN the floor would take is the driver's reading of the image the
update verified, which a superseding update overwrites, so a late ask would
otherwise advance the floor past an image that never booted. The gating case
has its own test, checked against the failure it exists for.

The eRoT's own floor already behaved this way and is unchanged: the only thing
that writes it is commit_self_svn_floor, which refuses a session that does
not read Committed. #565 is what gets a session there.

What is still missing is in GAPS.md: no firmware device parks at
SvnCommitPending, so both update scenarios dispatch SvnCommitRequest
themselves, the way they already dispatch BootConfirmed. Under that sit two
pieces, neither in this PR. The pldm-lib FdOps callback that turns a received
0x22 into the status is not in the pinned revision (c709ae4 predates it, and
it is not on pldm-lib main yet). The event-loop glue that reads the status
and answers is the other, for a device with commit_svn_floor and for the
eRoT's own floor with commit_self_svn_floor.

Tested: bazel test //services/... passes 38/38 and
bazel test --config=virt_ast10x0 //target/ast10x0/tests/integration/...
passes 26/26. ./pw presubmit is green.