feat: own runtime firmware candidates

Review threads live on the whole diff, not on one commit, so none are shown here - a thread's line means something in the branch's final form, and painting it into an intermediate step would put it on code it is not about.

docs/runtime-updates.mdmodified+5-5

Changes to docs/runtime-updates.md

		⋯363 linesShow the 363 lines above this hunk@@ -364,11 +364,11 @@ time. Neither path is a complete anti-rollback coordinator. Trusted clock
364	364	acquisition and protection against privileged clock/storage rollback remain
365	365	open. Control-loop freshness still uses its separate monotonic clock.
366	366
367		-Initial enrollment and the bounded persistent metadata protocol are available
368		-above. Complete authenticated maintenance/key revocation, the full storage-fault
369		-campaign and integration with signed image staging, then installed/known-good
370		-slot integrity, explicit
371		-health confirmation and rollback without lowering security floors. Then add
	367	+Initial enrollment, the bounded persistent metadata protocol and protected
	368	+signed-image preparation are available above. Complete authenticated
	369	+maintenance/key revocation and the full storage-fault campaign, then durable
	370	+candidate ownership, installed/known-good slot integrity, explicit health
	371	+confirmation and rollback without lowering security floors. Then add
372	372	the board bootloader/install protocol and measured power-loss, full-medium,
373	373	storage-latency and recovery campaigns. Local privileged filesystem tampering
374	374	is outside this host module's protection; it is not secure boot or hardware