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/docs/PER-PC-CREDENTIALS-ROLLOUT.md

@@ -103,6 +103,18 @@ The script compares before it writes, so `Always` costs nothing per cycle.
 A running agent picks up a changed `ServerPins` within about 60 seconds; no
 service restart is needed.
 
+**The registry wins.** The installer and the store upgrade also write
+`serverpins` into appsettings.json. When `ServerPins` exists in the registry
+(either view), even empty, the agent uses only the registry and ignores the
+appsettings.json pins; only a PC with no `ServerPins` value falls back to them.
+The agent log says which source is in effect (`Server certificate trust from
+registry` / `from appsettings.json`, and `Server pins changed, source ...`).
+
+- `-Pins <pin>[,<pin>]`: write exactly this set.
+- `-None`: write an EMPTY value. No pins, normal Windows certificate checks,
+  appsettings.json pins ignored.
+- `-Clear`: DELETE the value. The appsettings.json pins apply again (if any).
+
 **Gate:** on the pilot, `HKLM\SOFTWARE\GE\ShopDB` and
 `HKLM\SOFTWARE\WOW6432Node\GE\ShopDB` both hold `ServerPins` (REG_MULTI_SZ)
 equal to the pin on the settings page, and the next `report-asset-*.log` under
@@ -113,7 +125,10 @@ RESPONSE line.
 certificate a new key (a regenerated or re-issued certificate) changes the pin.
 Add the NEXT pin everywhere first: put the old AND the new pin in `-Pins`
 (`"<oldpin>,<newpin>"`), wait until every PC has both, only then switch the
-certificate on the server, then drop the old pin. Switching the server first
+certificate on the server, then retire the old pin by writing ONLY the new pin
+to the registry (`-Pins <newpin>`). Do not use `-Clear` for this: deleting the
+value brings back whatever pins appsettings.json carries, which may be the old
+one. Switching the server first
 cuts off every pinned PC, including its ability to receive the fixed pin list
 through anything that talks to ShopDB. A renewal that keeps the same key keeps
 the same pin. PCs trusted through the Root store (below) also need the new
@@ -312,7 +327,8 @@ enrolled PC. Block re-enrollment FIRST.
 4. Verify: the Fleet row reports the old agent version, and the reporter logs
    show `RESPONSE (shared key)`.
 5. Remove the PC from the pin entry's targets only if pinning itself is the
-   problem (`Set-ShopDBServerPins.ps1 -Clear` removes the value).
+   problem. `Set-ShopDBServerPins.ps1 -None` turns pinning off outright;
+   `-Clear` deletes the value, which falls back to any appsettings.json pins.
 6. Later, when moving the PC forward again, lift the block:
    `POST /api/endpoints/enrollment/assets/<assetid>/allow-reenroll` (or the
    same action in the UI). The PC enrolls on its next attempt once it runs