fix(ci): verify the binary inside the installers, not the loose target copy

The first fully signed run (signer CN=OLS Digital LLC) signed the app
binary, the MSI, the NSIS installer and the uninstaller, and skipped the
seven build-time DLLs. It still failed verification on
target\release\triple-c.exe. Tauri patches that file with bundle-type
information before each bundle, signs it, packages it, and patches it
again, so the loose copy is unsigned by design and is not what ships.

Verification now:
- checks the installers themselves;
- unpacks the MSI with `msiexec /a` and checks the binaries inside it;
- for NSIS, which can't be unpacked that way, requires the signing log to
  show that the app binary and the uninstaller were signed.

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

CLAUDE.md

@@ -857,14 +857,20 @@ merge, dispatch `build-app.yml` on the branch. Every publishing step there is ga
 - `scripts/windows-sign.ps1` is the sign command: `signtool sign /dlib` with SHA-256 and the
   Microsoft timestamp server, retried. Credentials never reach a command line — the dlib reads
   `AZURE_TENANT_ID` / `AZURE_CLIENT_ID` / `AZURE_CLIENT_SECRET` from the environment.
-  **It signs only an allowlist of what ships**, about 4 signatures per release. Tauri also
-  presents build-time tools: the WiX extension DLLs, the NSIS plugins, and the app binary a
-  second time for the second bundle type. Signing those would roughly triple the metered count
-  for no user-visible benefit. If the app ever ships resource DLLs or sidecars, extend the
+  **It signs only an allowlist of what ships**: 5 signatures per release (the app binary twice,
+  because Tauri re-patches it between the MSI and NSIS bundles; the MSI; the NSIS installer;
+  and its uninstaller). Tauri also presents build-time tools, the WiX extension DLLs and NSIS
+  plugins, and signing those would more than double the metered count for no user-visible
+  benefit. If the app ever ships resource DLLs or sidecars, extend the
   allowlist, or they will go out unsigned. Tauri reports a failed sign command only as
   "failed to run powershell", so the script keeps a transcript (`.code-signing/sign-output.log`,
   `signtool /debug` included), and the job prints it on failure.
-- `scripts/windows-verify-signatures.ps1` checks `signtool verify /pa` plus a timestamp.
+- `scripts/windows-verify-signatures.ps1` checks `signtool verify /pa` plus a timestamp on the
+  installers, and on the binaries **inside** the MSI (an administrative `msiexec /a` extract).
+  It deliberately does not check `target\release\triple-c.exe`: Tauri patches that file again
+  after packaging, so the loose copy is unsigned by design and is not what ships. For the NSIS
+  installer, which cannot be unpacked that way, it requires the signing log to show the app
+  binary and the uninstaller were signed.
 
 Secrets (repository): the three `AZURE_*` above plus `ARTIFACT_SIGNING_ENDPOINT`,
 `ARTIFACT_SIGNING_ACCOUNT_NAME`, `ARTIFACT_SIGNING_PROFILE_NAME`. They are referenced only by the