Let key-less PCs ask to enroll, and let an admin retry a trust-blocked PC

Found in the Windows VM re-test.

- A PC installed without the shared key got 401 from POST
  /api/endpoints/enroll while the shared key was allowed, so no request was
  recorded and no admin could approve it. Enroll now never refuses: a valid
  shared key only decides auto-issue on a clean match; no key or an invalid
  key creates or updates the one pending request for that hostname and
  serial. An approved request still issues only to its own nonce.
- A PC blocked with "server certificate not trusted by this PC" could never be
  queued again after trust was fixed, because the blocker comes from its last
  failed upgrade. Naming the PC in a wave now queues it when trust is its only
  blocker, and the response lists it under "retried"; "next n" still skips
  it. The Migration table lets such a PC be selected.
- counts.pending on GET /enrollment counts pending requests, including ones
  for unknown hostnames; counts.pendingcomputers keeps the per-computer figure.

plugins/endpoints/docs/PER-PC-CREDENTIALS-ROLLOUT.md

@@ -158,7 +158,12 @@ nothing. A non-CA leaf in Root trusts only this one server.
 
 If a wave reaches a PC that does not trust the certificate, the download fails
 and the Migration tab marks the PC **Blocked** with `server certificate not
-trusted by this PC`. Fix trust with the entry above, then queue the PC again.
+trusted by this PC`. The server only knows about trust from that failure, so
+the blocker stays until the PC is queued again. Fix trust with the entry above,
+then in the Migration tab tick the PC (a PC whose only blocker is this one keeps
+a checkbox and shows "Retry after fixing trust") and click **Upgrade selected**.
+**Upgrade next 25** never picks it, and a PC with any other blocker as well
+stays unselectable until that blocker is fixed.
 
 ## Phase 2: re-stamp the share's agent entries
 
@@ -233,7 +238,7 @@ Repeat until **Ready** is 0.
   in store`: upload 1.20. `agent too old for remote upgrade`: move it via the
   share (targeted agent entry as in phase 2). `server certificate not trusted
   by this PC`: add the PC to the certificate entry (phase 1), wait a cycle,
-  queue it again. `reenroll blocked`: the PC was rolled back on purpose; clear
+  then tick it and **Upgrade selected** (phase 1 explains the retry). `reenroll blocked`: the PC was rolled back on purpose; clear
   it with allow-reenroll (see Rollback) only when moving it forward again.
 - **Not reporting:** the PC has no working agent. It can only move via the
   share channel: add its hostname to a targeted 1.20 agent entry. It shows as
@@ -244,9 +249,13 @@ Repeat until **Ready** is 0.
   matched computer, search to choose another. The PC collects its credential on
   its next retry (within 15 minutes). **Reject** anything you do not recognise.
 - **Newly imaged PCs:** imaging installs 1.20 with the shared key, and the agent
-  auto-enrolls on first start. After the shared key is turned off (phase 6) a
-  new PC cannot auto-enroll: its request lands in Pending and an admin approves
-  it in the UI. That is the steady-state path for new PCs.
+  auto-enrolls on first start. A new PC can also be installed WITHOUT the
+  shared key at any time, before or after cutover (the generated installer's
+  "Include shared key" option off): the enroll call needs no key, so its request
+  lands in Pending and it waits there until an admin approves it in the UI. An
+  invalid key behaves the same (the server logs it). After the shared key is
+  turned off (phase 6) that is the only path, and the steady-state path for new
+  PCs.
 
 ## Phase 6: cutover