docs(packaging/windows): record the driver-signing fingerprint

The stable cert is live and CI is signing with it. Fills in the placeholder in
both docs and adds the one-liner to check an installed driver against it.

Thumbprint 4B8493E7CD565758D335F8F4F05C5A7261A13E02, verified off the .cer a real
windows-host build produced on the runner, not from the key material: RSA 3072,
valid to 2036, extensions 2.5.29.15/37/14 and nothing else. The decisive part is
that the pf-vdisplay and gamepad bundles now carry the SAME thumbprint — the
per-build fallback had each script mint its own 2048-bit cert, so they never
matched. That is what proves the secret reached the build rather than the
fallback quietly running again.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

SECURITY.md

@@ -74,7 +74,8 @@ us beyond the download itself.
   reach its code-signing certificate fails to build rather than falling back to a self-signed one.
   Check with `Get-AuthenticodeSignature punktfunk-host-setup-1.2.3.exe`.
 - **The Windows drivers** (virtual display, virtual gamepads) are signed with a stable self-signed
-  certificate, `CN=punktfunk-driver`, whose fingerprint is published in
+  certificate, `CN=punktfunk-driver`
+  (SHA-1 `4B8493E7CD565758D335F8F4F05C5A7261A13E02`), also published in
   [`packaging/windows/README.md`](packaging/windows/README.md). The installer has to add it to the
   machine's trusted roots for a self-signed driver to install at all, so — unlike the cases above —
   this signature does **not** authenticate the download: it gives the drivers a stable publisher