acceptance: a later FAIL blocks inheritance, ffboot is a component, the units fallback is valid

The inheritance walk skipped every record that was not a PASS on the
current fingerprint, so a FAIL or ERROR recorded after a PASS on the
same image was stepped over and the older PASS inherited into the next
campaign. The newest record on the fingerprint now decides: a PASS is
inherited, a FAIL or ERROR blocks it (reason failed-since), an ABORTED
run says nothing. Unit tests for all three orders.

ffboot, the tool that rewrites the boot environment on every install and
slot switch, was packaged from scripts/ outside every fingerprint. It
now lives in the recipe's files and the recipe inherits the manifest
class; the tree manifest tool fingerprints file components the same
way, and the update tests cover the component.

forgectrl.settings-bounds fell back to ui_units=mm, which the whitelist
refuses, so the always-required test failed on a fresh machine; the
fallback is metric.

meta-forgefirm/recipes-forgefirm/ffboot/ffboot.bb

@@ -6,9 +6,13 @@ layout."
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
 
-# ffboot's canonical home is scripts/ffboot in this repo (the factory-side
-# installer downloads it from there); the recipe packages that same file.
-FILESEXTRAPATHS:prepend := "${THISDIR}/../../../scripts:"
+# ffboot rewrites the boot environment on every install and slot switch,
+# so it is a fingerprinted component like the daemons: the manifest entry
+# records the two files, and the acceptance tests that cover ffboot are
+# invalidated when either moves (the installer copies the tool out of the
+# rootfs it just wrote).
+inherit forgefirm-manifest
+FORGEFIRM_MANIFEST_SRC = "${THISDIR}/files"
 
 SRC_URI = " \
     file://ffboot \