kms-website: auto-fetch + auto-install GVLKs (no manual key lookup)

Scripts now detect the running edition and fetch the matching GVLK from a
published key list instead of requiring the user to copy one from the table.

- data/products.yaml: add editionid to every Windows/Server entry, plus build
  numbers where an EditionID spans releases (LTSC, Server). Azure Edition left
  unmapped on purpose (collides with Datacenter; KMS may fail there anyway).
- /keys.json: Hugo KEYS output format renders products.yaml as JSON
  (single source of truth). layouts/index.keys.json.
- setup-kms.ps1: when no VL key is installed, read registry EditionID
  (+build/ProductType for server) -> fetch /keys.json -> slmgr /ipk the match
  -> activate. Only acts when not already licensed (never clobbers retail).
- kms-bootstrap.ps1: same for Windows; for Office/Project/Visio, read
  Click-to-Run ProductReleaseIds -> ospp /inpkey the matching GVLK -> /act.
- $env:KMS_KEYS_URL overrides the key-list URL.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

hugo.toml

@@ -14,6 +14,18 @@ disableKinds = ["taxonomy", "term", "RSS", "sitemap", "404"]
   kmsPort      = 1688
   bootstrapURL = "/scripts/kms-bootstrap.ps1"
   setupURL     = "/scripts/setup-kms.ps1"
+  keysURL      = "/keys.json"
+
+# Publish data/products.yaml as machine-readable JSON at /keys.json so the
+# activation scripts can fetch the GVLKs (single source of truth, no hardcoding).
+# /keys.json is carved out of Anubis alongside /scripts (see stacks/kms).
+[outputs]
+  home = ["HTML", "KEYS"]
+
+[outputFormats.KEYS]
+  mediaType   = "application/json"
+  baseName    = "keys"
+  isPlainText = true
 
 [markup]
   [markup.goldmark.renderer]