orchestrator: add TrialBoot capability trait

[chrysh]

TL;DR: Trait-only PR. TrialBoot is the commit gate activation leaves open:
keep an image that was activated but not committed once its boot was judged,
or throw it away.

Part of #377, 9elements#21.

Summary

Activating an update picks the staged image as the next thing to boot and
stops there, whether the eRoT does that itself through Updatable::activate
or a PLDM firmware device does it for the eRoT. Updatable's docs already
point at a TrialBoot capability as the other half; that trait did not
exist. This adds it to orchestrator-capabilities: is_pending, confirm,
revert.

confirm and revert take no arguments. A device has at most one trial open
at a time, the one the last activation armed, so there is nothing to name,
and which slot is which stays behind the seam as it does in Updatable.

One contract, both implementations

The same trait covers a downstream device behind interposed flash and the
eRoT's own image. They differ in who judges the boot, not in what confirm or
revert means. A device that commits on its own, a PLDM firmware device
picking its own slot, has no TrialBoot on the eRoT side, the same split
SvnFloor already makes.

Three contract points:

• is_pending is answerable from stored state alone, because the image that
  confirms a self-update is not the image that armed it.
• The arming counts for the next boot only, but the record of the trial
  outlives it. An image that hangs, or an eRoT that loses power during the
  trial, boots the confirmed slot again with no call from anyone; the record
  stays open until confirm or revert, so an orchestrator that rebooted
  mid-update finds the trial again instead of losing it.
• revert also disarms. An orchestrator that drops an activation before
  resetting the device needs the next boot to run the confirmed slot even
  though the trial image never booted.

Both calls are safe to repeat: with no trial open they succeed and do
nothing, matching SvnFloor::advance.

confirm moves slot metadata only. Raising the anti-rollback floor is
SvnFloor::advance and happens later, on the UA's UpdateSecurityRevision
(DSP0267 1.3.0, command 0x22), which is what keeps revert able to fall back
to an image that still boots. See #464.

Why not a method on Updatable

For self-update, staging and confirm run in different boots of different
images. The Updatable instance that staged the payload no longer exists
when confirm runs. A method on Updatable cannot model that.

Also considered and rejected: the consuming-session shape of #459 (a
session's compile-time guarantee cannot cross a power cycle, which is the
boundary this trait exists to span), and a constructor returning
Option<Trial> (models only cold-boot recovery, not the downstream happy
path where the trial opens mid-session).

Tests

Seven host tests, both implementations driven through one generic
apply_verdict<T: TrialBoot> so the shared contract is what is under test: a
healthy downstream trial becomes confirmed, one nobody confirms falls back
yet stays open, revert before the trial boots disarms the next boot, the eRoT
confirms from the boot its trial started, an eRoT trial that never confirms
falls back on the next reset, a replayed resolution is a no-op, errors
surface through the generic seam.

Not in this PR

The implementations. What backs the trial record durably is open
(#383, #384): services/storage is still a stub, so the
eRoT-side impl has nowhere to keep the record yet.