driver: Bring the spare slot up to date after a commit

[chrysh]

Rebased onto ocp-global-demo-wip now that #511 merged. One commit, no stack note. The only rebase fix was Event::UpdateVerified, which no longer carries a component id.

This is SOW P7, "additional partitions up to date", in its cheaper shape.

A commit re-stages the image that just proved itself, so the slot the device stopped booting from stops holding the version from before the update. Nothing activates afterwards: the payload lands in the inactive slot and stays there.

It re-stages rather than copying between slots, because Updatable keeps slot identity on the device's side ("which slot is inactive is device state"). The candidate is still in the staging region: the machine runs one job at a time, so nothing has overwritten it since the activation. The cost is a second full transfer. Copying between slots instead needs a seam that names them, which is the larger decision, parked for the week of 2026-10-11.

The pump runs the pass, not the commit executor: a transfer takes minutes and an executor must return promptly. The SM is never told the result, because a verdict would start a second activation of an image the device already runs. A device that fails the pass reports SlotResyncFailed and the job ends there, with the running image committed either way.

Rebase note: the merged pump parks at Staged and emits no UpdateVerified until the crypto verify client (#490) is wired, and the candidate-verifier seam this branch was written against did not survive into #506. The tests here pump until the device holds the payload and then dispatch the verdict directly, so they exercise what follows activation rather than the pump reaching it. The verify session and UpdateVerifier board seam the earlier revision carried are gone with it; abandon_job only tells the device to drop what it was staging.

Two things this assumes, both worth a second opinion:

Staged bytes in the spare slot are what a fallback boots. Updatable says writes go to the inactive slot and activate flips the metadata, but it does not say a slot written and never activated is bootable. That is the staging-is-inert slot question from the #431 follow-ups, still open with Anthony.

An update that is submitted and then discarded between the activation and the confirmed boot cancels the re-sync for good: the region changed hands, so re-staging from it would write the wrong image. The spare slot then keeps pre-update firmware and nothing reports it, because by commit time the driver cannot tell that case from "no update to re-sync". Telling them apart needs a tombstone, which I have not added.