0.2.4: the trustlet comes from the active slot, unpinned, and a refusal says why

0.2.3's manifest pinned the sha256 of one Android build's focal64
(16.82.0, the build the dev phone runs). Fairphone re-signs the trustlet
every release, so that pin matched exactly one of the six builds seen,
and two of two field reports had no sensor: one user on 16.100.0 edited
the manifest by hand, another ended up with a file QTEE refuses.

The manifest now carries '-' instead of a hash and depends on
fp6-vendor-blobs 1-r3, which tries the active slot first and verifies the
image's structure; QTEE's signature check is the gate it always was (one
flipped byte -> ERROR_ELF_SIGNATURE_ERROR, measured 2026-09-03 and again
today).

post-install reassembles the trustlet right away, so 'apk add' no longer
needs a boot for it. post-upgrade re-derives it from the active slot,
which replaces a hand-placed or wrongly pinned file, and then restarts
the daemon -- a plain restart, so a daemon that exited on a refused
trustlet comes back up on the re-derived one.

loadFromBuffer failures name the loader's verdict. The field's first
report was a bare result=12; it now reads ERROR_ELF_SIGNATURE_ERROR with
what to do about it. Probed on the phone with this build: a one-byte
tampered image and 100000 random bytes both print it, the pristine image
loads, and the suites pass 8/8.

packaging/build-package.sh

@@ -100,7 +100,7 @@ rm -rf "$PKG"
 mkdir -p "$PKG"
 cp "$SRC/packaging/APKBUILD" "$PKG/APKBUILD"
 # install= scripts are read from the aport dir, not from source=
-cp "$SRC/packaging/fingerprintd.post-upgrade" "$PKG/"
+cp "$SRC/packaging/fingerprintd.post-install" "$SRC/packaging/fingerprintd.post-upgrade" "$PKG/"
 mv "fingerprintd-$VER.tar.gz" "$PKG/"
 sed -i "s/^pkgver=.*/pkgver=$VER/" "$PKG/APKBUILD"
 # a throwaway signing key: phones trust the registry-signed APKINDEX, not