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/fingerprintd.post-upgrade

@@ -2,14 +2,20 @@
 # SPDX-License-Identifier: GPL-3.0-only
 # SPDX-FileCopyrightText: Copyright (C) 2026 Catcrafts®
 #
-# apk replaces /usr/bin/fingerprintd on disk and leaves the running daemon
-# alone. The phone is then a working matcher running the OLD code: the journal
-# says MATCH and whatever the upgrade added is dead until a reboot, which is
-# how 0.2.2's FingerMatched signal first presented (fp6 journal, fingerprint
-# lane, 2026-09-05). Restart it if it is running.
+# Two things an upgrade must do on a running phone. First re-derive the
+# trustlet from the active slot: 0.2.3 pinned one Android build's hash, so a
+# phone on any other build has no trustlet, or a hand-placed one, and
+# --refresh replaces it with the phone's own (fp6 journal, fingerprint lane,
+# 2026-09-11). --if-device keeps this a no-op inside build/CI chroots.
+/usr/lib/fp6-vendor-blobs/extract --if-device --refresh || :
 #
-# try-restart: a daemon that is not running -- no /dev/tee0, no trustlet --
-# stays not running. Inside a build or CI chroot there is no systemd to ask.
+# Then restart the daemon: apk replaces /usr/bin/fingerprintd on disk and
+# leaves the running one alone, so the phone would keep matching with the OLD
+# code until a reboot (how 0.2.2's FingerMatched signal first presented,
+# 2026-09-05). A plain restart rather than try-restart: a daemon that exited
+# on a refused trustlet is not running and must come up on the re-derived
+# file, and the unit's ConditionPathExists lines keep this inert on a phone
+# with no trustlet or no /dev/tee0. No systemd inside a chroot.
 [ -d /run/systemd/system ] || exit 0
-systemctl try-restart fingerprintd.service 2>/dev/null || :
+systemctl restart fingerprintd.service 2>/dev/null || :
 exit 0