feat(anc): wire check-hotfix into node wrapper behind ENABLE_PROVISIONING_HOTFIX

[Devinwong]

2.1c - Wire check-hotfix into the node wrapper (shell only)

POC / M1 draft. Shell-only wiring for the Provisioning-Hotfix flow. No Go changes.

Enablement (where this sits in the rollout chain)

This env gate is the on-node terminal of the design's region-staged opt-in:
EnableProvisioningHotfix aks-rp toggle (AKS Toggles-as-code, per region) -> absvc
respects toggle -> ANC respects toggle. This PR implements only the last hop ("ANC
respects toggle"). The env var name mirrors the toggle/contract name to match the
existing contract->env convention (e.g. EnableIMDSRestriction -> ENABLE_IMDS_RESTRICTION),
keeping the chain traceable. Wiring absvc to render this var from a contract field is a
separate follow-up PR; the aks-rp toggle + toggle YAML live in the aks-rp repo. Until
those land, the var renders unset everywhere, so this change is inert (default-off).

Note: 2.1d (#8717) relaxes this env gate, moving the on/off decision into the Go binary
via the enable_provisioning_hotfix contract field (single source of truth). This PR
intentionally ADDS the gate; #8717 relaxes it, so each PR stays reviewable on its own.

What this does

Adds one call to the check-hotfix subcommand (added in 2.1b) inside
aks-node-controller-wrapper.sh, gated behind a new env flag ENABLE_PROVISIONING_HOTFIX
that is OFF by default. check-hotfix reads the hotfix pointer from the LPS endpoint
(IMDS-attested) and refreshes
$HOTFIX_JSON, which the existing download-hotfix block consumes - so it must run
first. The call is fail-open (the command always exits 0) and additionally wrapped
defensively so it can never block provisioning.

Default-off / fail-open guarantee

When ENABLE_PROVISIONING_HOTFIX is unset, empty, or any value other than the literal
string true, the wrapper behaves EXACTLY as it does today. This preserves the
6-month VHD backward-compatibility window: older VHDs running newer CSE, and newer
VHDs running older CSE, are unaffected unless the flag is explicitly turned on.

Known-safe: old VHD + flag on

If ENABLE_PROVISIONING_HOTFIX=true ever reaches a node whose VHD-baked ANC binary predates
2.1b, "$BIN_PATH" check-hotfix is an unknown subcommand and exits non-zero. The
if ... else log "...continuing (fail-open)" fi wrapper swallows that error, so
provisioning still proceeds unchanged. This path is covered by shellspec case 4 below
(check-hotfix exits non-zero -> wrapper still provisions), which models the missing
subcommand. This matters for the 6-month VHD support window.

Before / after flow

Flag off (default - unchanged):

guard config/nbc -> [download-hotfix if $HOTFIX_JSON] -> select binary -> provision

Flag on (ENABLE_PROVISIONING_HOTFIX=true):

guard config/nbc -> check-hotfix (refresh pointer) -> [download-hotfix if $HOTFIX_JSON] -> select binary -> provision

Notes

• check-hotfix takes no flags/args; it reads the AKSNodeConfig from its default
  on-node path internally for the LPS endpoint (IMDS-attested) it reads, so the wrapper passes nothing.
• HOTFIX_JSON is parameterized as ${HOTFIX_JSON:-<default>} to match the existing
  BIN_PATH / CONFIG_PATH / NBC_CMD_PATH pattern and to allow shellspec to exercise
  the download-hotfix branch. Production default path is unchanged.
• Write/read handoff verified: check-hotfix writes the pointer to defaultHotfixVersionPath
  (/opt/azure/containers/aks-node-controller-hotfix.json, hotfix.go) and download-hotfix
  reads the same constant. The wrapper's HOTFIX_JSON default is byte-identical, and the
  Go hotfixVersionPath override exists only for tests (no env/production override and
  check-hotfix takes no path flag), so the two never diverge on a node.
• POSIX compliant ([ ], =, ${VAR:-}); passes shellcheck generic + POSIX (SC3010/SC3014)
  and the wrapper shellspec suite (8 examples, 0 failures).

Tests

New shellspec cases in aks_node_controller_wrapper_spec.sh:

1. flag unset -> check-hotfix NOT called (no behavior change)
2. non-true value (e.g. "1") -> treated as disabled
3. flag = true -> check-hotfix runs BEFORE download-hotfix, provision last
4. check-hotfix exits non-zero -> wrapper still proceeds to provision (fail-open)

Stack

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

Base is set to the 2.1b branch so the diff shows only the wrapper + shellspec changes.
Will retarget to main as the stack merges down.

This unblocks the on-node e2e PoC tests (fail-open and multi-base) since check-hotfix
is otherwise never invoked at boot.

[Devinwong]

Read-channel pivot: the hotfix-pointer read moves from Option 2 (kube-system anc-hotfix-version ConfigMap via apiserver + bootstrap token) to Option 4 (LPS endpoint, IMDS-attested), validated by e2e showing the node can reach LPS pre-kubelet. The fetch/auth rewrite lives in #8696 (2.1b). This wrapper wiring is channel-agnostic: the check-hotfix -> download-hotfix call sequence, the ENABLE_PROVISIONING_HOTFIX gate (relaxed by 2.1d via the enable_provisioning_hotfix contract field), and the fail-open semantics are all unchanged. Only comments/wording were updated to name the new read channel.

[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