Always pin the server, let the registry own pins, and survive a revoke mid-upgrade

Found in the Windows VM re-test.

- A CA-flagged server certificate (common with a plain openssl self-signed
  cert) produced an installer package with no pin at all, so agent 1.20
  refused the server. The package now always carries the SPKI pin of the
  certificate PCs receive; the CA flag only skips the trusted-root import.
  When an uploaded CA-flagged certificate differs from the server's own, both
  pins are included. The build response carries X-ShopDB-Build-Warning and the
  installer logs what older agents need.
- Pins written into appsettings.json by the installer were merged with the
  registry, so removing a pin from HKLM never took effect. When the ServerPins
  value exists in the registry it is now authoritative, even when empty;
  appsettings pins apply only when it is absent. Set-ShopDBServerPins.ps1
  -Clear deletes the value; new -None writes an empty value (no pins).
- A script or package download sent with a credential revoked moments earlier
  got 401 CREDENTIAL_INVALID and failed the command. The agent now retries that
  download once with the shared key and records the fallback in the result.

plugins/endpoints/AGENT-CONTRACT.md

@@ -641,7 +641,7 @@ All use the standard error envelope (`data.error.code`).
 
 | HTTP | Code | Meaning | Agent action |
 |---|---|---|---|
-| 401 | `CREDENTIAL_INVALID` | unknown or revoked credential | delete credential.bin, fall back to the shared key, wake enrollment |
+| 401 | `CREDENTIAL_INVALID` | unknown or revoked credential | delete credential.bin, fall back to the shared key, wake enrollment; a `scriptbody` / `apppackage` download retries once (shared key, or a credential enrolled meanwhile) and the command result carries `detail.authfallback`; with no shared key the command fails saying so |
 | 401 | `SHARED_KEY_REFUSED` | shared key sent, but this PC is enrolled or the shared key is switched off | wake enrollment; use the credential |
 | 403 | `ASSET_MISMATCH` | the credential's asset differs from the hostname/assetid named in the request | log; do not retry the same request |
 
@@ -674,8 +674,16 @@ for the SYSTEM reporter scripts.
 ### 9.5 Server pins
 
 - `HKLM\SOFTWARE\GE\ShopDB` `ServerPins` (REG_MULTI_SZ, both registry views)
-  merged with `serverpins` (string array) in appsettings.json. Legacy
-  `servercertthumbprint` is still honoured.
+  is authoritative whenever the value EXISTS in either view, even empty: its
+  pins (possibly none) are the whole set and `serverpins` / legacy
+  `servercertthumbprint` in appsettings.json are ignored. Only when the value
+  is absent in both views do the appsettings.json pins apply. The agent logs
+  which source is in effect (`registry` or `appsettings.json`) at startup and
+  on every change.
+- `Set-ShopDBServerPins.ps1 -Pins <pins>` writes the set; `-None` writes an
+  empty value (registry authoritative, no pins, normal chain validation);
+  `-Clear` deletes the value (appsettings.json pins apply again). To retire an
+  old pin after a rotation, write only the new pin.
 - A pin is the lowercase hex SHA-256 of the server leaf certificate's
   SubjectPublicKeyInfo. The Server Certificate settings page shows it
   (`spkisha256` on `GET /api/endpoints/settings/server-cert`);