docs: add orchestrator runtime concept page and board composition

[rusty1968]

Introduces a design page on the orchestrator runtime and how it turns hardware and IPC activity into the events the state machine consumes.

[chrysh]

Add to docs/src/SUMMARY.md:

* [Runtime](./design/orchestrator/orchestrator-runtime.md)     

[chrysh]

The runtime page says "The three share one object_wait, so a slow image hash on one path cannot delay a boot window on another". I don't think the wait group gives us that.

object_wait bounds how long the loop waits, not how long it works. While an effect executor runs, the loop is not in the wait at all, so no deadline is in effect. Verify is inline today: Effect::VerifyFirmware calls Verifier::verify in driver/src/driver.rs:86. With a 200ms boot window and a 2s image hash, the window lapses at 200ms, nobody notices until the hash returns at 2s, and Event::Timeout fires 1.8s late.

What actually keeps the loop live is the other half, which the page does not state: every decode and every effect executor returns promptly. That is why staging is a pump rather than a single transfer call. Could the page say that rule directly instead of deriving liveness from the shared wait?

Two related questions:

• The platform page says commands to crypto and storage are fire-and-forget and every reply comes back as a queued event. channel_transact is synchronous and it is the only outbound primitive the kernel gives us. What is the intended shape there?
• Sources with no signal (the BootWatch walkers, later the update pump) need the loop to wake on its own. Would an adaptive deadline cover it: now while a job is live, wait_deadline() when idle?

[chrysh]

The page says BootWatchdogs folds all armed boot windows and the commit window into a single deadline. There is a second tracker for the same windows though: release_reset arms a BootWatch per component, and poll_boot_walks(now_millis) returns next_deadline_millis plus Event::Timeout(id) on WalkVerdict::Failed (driver/src/driver.rs:150).

So today the same boot window is tracked twice, in two units (Instant in BootWatchdogs, u64 millis in the walkers), and both paths produce Event::Timeout(id). The state machine drops the second one as stale via is_awaiting_boot, so nothing breaks, but two owners of one deadline is the failure mode we already agreed to avoid elsewhere.

The part that does break: the walkers are polled and nothing signals the loop on their behalf. If wait_deadline() only reflects BootWatchdogs, the loop sleeps straight past a walker's deadline.

Which one is meant to survive?

[chrysh]

poll_boot_walks(now_millis) returns Event::Timeout(id) when a walk hits WalkVerdict::Failed (services/orchestrator/driver/src/driver.rs:150), so there is an edge from the driver back into dispatch that the picture does not show. Worth an arrow?

[leongross]

Is the boot monitoring really steered by hardware interrupts? Our trait based implementation as of now is naturally agnostic, but when we discussed this we talked about polling the GPIO lines, instead of waiting for real hardware interrupts handled by the hardware NVIC and ISRs.

I understand what you want to say by this, but if we are not relying on hardware inerrupts we should adapt the wording here.

[leongross]

What does this decoder look like and where is it defined?

[leongross]

So what is the use case for a registered member to resolve to no Event?
If this is not the case, we should be precise and say

Suggested change

	signaled. Each member resolves to at most one `Event`:
	signaled. Each member maps to exactly one `Event`:

[leongross]

Could we link the source defintiion/link to pigweed kernel upstream sources here?