Orchestrator: golden partition fallback vs. policy

[chrysh]

Does the orchestrator always boot into golden partition on fail, or does it take policy into account?

Context: https://github.com/OpenPRoT/openprot/pull/357/changes#diff-ed5cbc8c52e870e0a1d115475283d5916ded79625514a3d8b77cff48fb61cc3cR255

cc @FerralCoder @rusty1968

[FerralCoder]

recovery flow is policy - there may be redundant A/B/C partitions to try before falling back to golden/recovery image. If redundant partitions are available, we would try those first. Falling back to golden/recovery image is last resort

[chrysh]

@rusty1968 this is the policy question for that, concretely.

The core counts recovery attempts and caps them. Effect::RecoverComponent
carries attempt, and the driver is meant to pick a different source per
attempt: slot A on 0, slot B on 1, golden on 2. What should the driver do when
it runs out of sources before the core runs out of attempts?

Option one, return an error. It reaches the SM as EffectError and is treated
fail-closed, so a board with three sources latches Locked on attempt 3 even if
the cap is 5. The board's source count silently sets the real cap.

Option two, clamp to the last source and keep restoring from it until the
core's cap is spent. The cap stays meaningful, but the retries repeat a source
that already failed.

A board with one source never sees the difference, it just repeats the same
restore each attempt. The Recovery capability trait I am writing currently says
exhausted is an actuation error, which is option one. Which do you want?

[rusty1968]

Addressed at the SM level by #473 as a third option beyond the two originally proposed:

• not option one (return an error → EffectError → unconditional Locked, which as @chrysh noted lets a board's source count silently set a lower real cap than the core's, even for Isolable/Cascading components)
• not option two (clamp to the last source and burn remaining attempts repeating a restore that already failed)
• instead: the driver reports exhaustion as its own event, and the SM gates it through the same FailurePolicy machinery as the retry-cap-exhausted path (exhaust_recovery, shared between both) — Isolable/Cascading components are skipped, only Required locks the platform.