Name the signing method the release actually used

[its-janghoon]

Every release published so far has told readers:

Windows binaries are signed through Azure Trusted Signing.

That was not true. This repository signs Windows with the organization Authenticode certificate — the
Azure steps skip, the PFX steps run. Checked against the published v0.2.0 run: Sign with Azure Trusted Signing skipped, Sign with the organization Authenticode certificate succeeded, and the notes still
named Azure.

The workflow already forbids exactly this, in the comment above the outputs it carries to publish:

Notes that claim a signature the run did not produce are worse than no claim: a reader has no way to
tell, and the whole point of saying "signed" is that it can be relied on.

The mechanism was one output short of being able to honour it. signed is a boolean about SUCCESS, so it
cannot say which of the two configured methods produced the signature, and the notes filled that gap with
the preferred method rather than the used one. sign-windows now also exports method, publish receives
it, and the notes name what ran.

An unrecognised value is described without naming a method rather than guessed at — "signed, verify with
signtool verify /pa or against the provenance attestation" is vaguer but true, and a wrong provenance
claim is the worse failure because a reader cannot detect it.

v0.2.0's published notes were corrected in place, since the false claim is already out there.

Found while dispatching the release: the dispatch path itself was fine — repository id matches the pinned
guard, the workflow is active and present on the default branch, and a dry run signed and verified both
the binaries and the installer before the real publish.