Depend on the extractor that understands our manifest, and restart on upgrade

fp6-vendor-blobs learned the mbn directive in 1-r2. The extractor before it
exits on an unknown directive, so a fresh flash with 1-r1 and our
20-focal64.manifest processes the audio fragment and then fails the blobs unit
on ours: a red unit, no trustlet, and nothing in the daemon's own logs to say
why. Saying >=1-r2 makes apk refuse a combination that cannot work instead of
installing one that fails at first boot. Existing installs never saw this --
the old fast path only checks file lines and exits before the dispatcher.

apk also swaps the binary on disk and leaves the running daemon alone, which is
how 0.2.2's FingerMatched signal first presented: a clean MATCH in the journal
and nothing downstream, because the boot's 0.1.3 was still answering. A
post-upgrade try-restart closes that. A daemon that is not running stays not
running, and a build chroot without systemd is left alone.

0.2.3, so the package CI publishes it.

packaging/fingerprintd.post-upgrade

@@ -0,0 +1,15 @@
+#!/bin/sh
+# 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.
+#
+# 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.
+[ -d /run/systemd/system ] || exit 0
+systemctl try-restart fingerprintd.service 2>/dev/null || :
+exit 0