feat(anc): add check-hotfix subcommand to read hotfix pointer from LPS

[Devinwong]

Add a check-hotfix subcommand that reads the hotfix pointer from the live-patching-service

This adds a new fail-open check-hotfix subcommand to aks-node-controller. It reads a base-to-hotfix version pointer map from the live-patching-service (LPS) over an IMDS-attested HTTPS path that is reachable before kubelet is up, and writes that pointer to the file download-hotfix already consumes. download-hotfix then re-resolves the pointer and keeps its existing patch-only, strictly-higher gating. check-hotfix only fetches and stages the pointer - it never installs anything and never blocks provisioning.

Stacking

This branch is stacked on the base-to-version hotfix map change (PR #8694). The PR base is set to that branch so the diff shows only this change (app.go wiring + checkhotfix.go + checkhotfix_test.go). It must merge after #8694; if #8694 merges first, retarget this PR to main.

main
 \- #8694  2.1a  base->version hotfix map (Go)
     \- #8696  2.1b  check-hotfix LPS endpoint reader (Go)        <- this PR
         \- #8715  2.1c  wire check-hotfix into wrapper (shell)
             \- #8717  2.1d  enable_provisioning_hotfix contract field + Go self-gate

This PR's check-hotfix command is always-on by itself - it has no feature gate. The gating arrives later in 2.1d (#8717), which adds an enable_provisioning_hotfix contract field so check-hotfix self-gates on it.

What it does

1. Reads the hotfix pointer from the LPS with a raw net/http HTTPS GET (no client-go dependency). The transport mirrors the proven pre-kubelet connectivity path:
   • TLS ServerName is pinned to the LPS SNI host, while a custom dialer forces the TCP connection to the apiserver FQDN on port 443 (the curl --resolve trick). The apiserver front routes the pinned SNI to the LPS backend.
   • Authorization is the IMDS attested-data document signature (http://169.254.169.254/metadata/attested/document). IMDS is reachable pre-kubelet, so this works before any kube credential exists. The token fetch is injectable for tests.
   • The server certificate is verified against the cluster CA carried in the provision config (base64 PEM); the CA source used is logged. check-hotfix runs before the provisioning scripts, so the decoded on-node CA file (/etc/kubernetes/certs/ca.crt) does not exist yet - the provision config is the only credential source guaranteed to be present at this point.
   • Short-timeout (~10s) client so provisioning is never delayed.
2. Parses the response: the body is the {"hotfixes":{...}} JSON object, which unmarshals directly into the same config type download-hotfix uses, so both commands share one parser and data contract.
3. Writes the pointer to /opt/azure/containers/aks-node-controller-hotfix.json in the same {"hotfixes":{...}} shape (atomic temp-file + rename), so download-hotfix re-resolves it and applies its unchanged gating.
4. Fail-open: the command always exits 0 so provisioning is never blocked. Any timeout / connection error / 5xx / parse failure is logged, emitted as telemetry, and swallowed.
5. Not-enrolled is benign: a reachable LPS that has nothing for this node yet (HTTP 401 / 403 / 404) is a clean no-op, not a failure. The LPS authorizes in two stages (attestation, then agent-pool authorization), so a node whose pool is not yet enrolled in live-patching gets a 401 - the expected steady state on a freshly enabled cluster. These responses stage no overlay and are reported as notEnrolled.
6. Cold-start fallback: only when the LPS could not be reached or talked to (transport failure / 5xx), it reads a lenient top-level hotfixes object embedded in the provision config and uses that. (Marked with a TODO to switch to a typed config field once that contract exists.)
7. Telemetry: guest-agent events under task name CheckHotfix with outcomes lpsRead, noHotfixForBase, notEnrolled, customDataFallback, failed.

Open dependency (placeholder route)

The LPS route and response schema for the base-to-hotfix pointer are a planned-maintenance deliverable that is not finalized yet; the connectivity prototype only proved reachability of the LPS read path. The route is a clearly-named placeholder constant (lpsHotfixPath = "/v1/anc-hotfix") with a TODO, and the expected response body is documented as {"hotfixes":{"<YYYYMM.DD base>":"<YYYYMM.DD.PATCH>"}}. The IMDS/LPS client helpers mirror the connectivity prototype and are flagged in-code to be de-duplicated into a shared LPS client when that lands.

Net effect (examples)

LPS serves the pointer body:

{"hotfixes":{"202604.01":"202604.01.1","202605.01":"202605.01.2"}}

check-hotfix stages /opt/azure/containers/aks-node-controller-hotfix.json:

{"hotfixes":{"202604.01":"202604.01.1","202605.01":"202605.01.2"}}

Node baked ANC version	LPS read	check-hotfix outcome	download-hotfix then does
202604.01.0	OK	lpsRead	base 202604.01 -> 202604.01.1, patch 1 > 0, upgrades
202605.01.2	OK	lpsRead	base 202605.01 -> 202605.01.2, patch not higher, no-op
202607.15.0	OK (no matching base)	noHotfixForBase	no pointer for this base, no-op
any	401 / 403 / 404 (pool not enrolled)	notEnrolled	no overlay staged, no-op
202604.01.0	unreachable (timeout / 5xx), provision config has embedded hotfixes	customDataFallback	reads staged fallback pointer, resolves as above
202604.01.0	unreachable, no fallback present	failed (still exit 0)	nothing staged, no-op

Tests

New network-free unit tests (LPS fetcher and attested-token injected, no real networking): success read+write, benign not-enrolled 401/403/404 no-op (no overlay), timeout/connection/5xx fail-open, invalid pointer JSON fail-open, noHotfixForBase, cold-start fallback (and no-pointer failure), telemetry outcomes and always-exit-0 wiring, shared-parser equivalence with download-hotfix, attested-token injection, provision-config endpoint/CA resolution, and the SNI-pinned TLS client (provision-config trust vs insecure fallback).

All new tests pass. The full go test ./... run shows no new failures versus the base branch. The only failures are pre-existing Windows-only environmental ones (they need /etc/os-release, bash, and unix file perms) that pass in Linux CI.

Note: wiring this command into the provisioning wrapper script is intentionally out of scope for this PR and will land separately behind a feature flag.

[github-actions]

Changes cached containers or packages on windows VHDs

Please get a Windows SIG member to approve.

The following dif file shows any additions or deletions from what will be cached on windows VHDs organised by VHD type.

• Additions are new things cached.
• Deletions are things no longer cached.

diff --git a/vhd_files/2022-containerd-gen2.txt b/vhd_files/2022-containerd-gen2.txt
index 7039bac..c51a47f 100644
--- a/vhd_files/2022-containerd-gen2.txt
+++ b/vhd_files/2022-containerd-gen2.txt
@@ -122,0 +123 @@ mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.34.6-windows-hp
+mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.2-windows-hp
@@ -124 +124,0 @@ mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.3-windows-hp
-mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.4-windows-hp
diff --git a/vhd_files/2022-containerd.txt b/vhd_files/2022-containerd.txt
index 5915cf1..7312c49 100644
--- a/vhd_files/2022-containerd.txt
+++ b/vhd_files/2022-containerd.txt
@@ -122,0 +123 @@ mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.34.6-windows-hp
+mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.2-windows-hp
@@ -124 +124,0 @@ mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.3-windows-hp
-mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.4-windows-hp
diff --git a/vhd_files/2025-gen2.txt b/vhd_files/2025-gen2.txt
index 37d9326..36e3641 100644
--- a/vhd_files/2025-gen2.txt
+++ b/vhd_files/2025-gen2.txt
@@ -52,0 +53 @@ mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.34.6-windows-hp
+mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.2-windows-hp
@@ -54 +54,0 @@ mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.3-windows-hp
-mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.4-windows-hp
diff --git a/vhd_files/2025.txt b/vhd_files/2025.txt
index 5b08280..b8873d5 100644
--- a/vhd_files/2025.txt
+++ b/vhd_files/2025.txt
@@ -52,0 +53 @@ mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.34.6-windows-hp
+mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.2-windows-hp
@@ -54 +54,0 @@ mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.3-windows-hp
-mcr.microsoft.com/oss/v2/kubernetes-csi/azurefile-csi:v1.35.4-windows-hp