Unblock CI: 1ES grace period for deprecated Vanilla Windows 2022 SDL image

[Lara Bailen Boluda (larabail)]

What broke

Every build in this repo fails in stage 🔒 SDLSources, task 1ES PT Pre-Job:

##[error]1ES PT Error: Vanilla Windows 2022 with .NET 6 pre-installed is being
deprecated by Azure because .NET 6 has reached end of life. Please switch to
1ES PT - Vanilla Windows 2025 (VanillaWindows2025-1ESPT):
https://aka.ms/1espt/vanillawindows2022
1ESPT_ALLOWDEPRECATEDIMAGESUNTILSEP_30_2026 = ''

No PR caused this. 1ES flipped the check from a warning to a hard error on
2026-08-25, server-side:

Build	Date	PR	Result
1355	2026-08-26	#416	succeeded — message present, non-blocking
1356	2026-09-01	#419	failed
1357	2026-09-10	#420	failed (inherited)

This blocks #419 and #420. Neither is at fault. Linux tests are unaffected and
still pass (279 passed / 0 failed) — this is only the Windows SDL/compliance pool.

What I changed

One file: .ci/vars.yml. Added the grace-period variable that 1ES documents:

1ESPT_ALLOWDEPRECATEDIMAGESUNTILSEP_30_2026: 'true'

vars.yml is pulled in at global pipeline scope by both validationBuild.yml and
previewBuild.yml, so one entry covers all three places that reference the
deprecated image — validationBuild.yml:38, previewBuild.yml:34 and
templates/common-compliance-stages.yml:7. I confirmed the scope by expanding the
pipeline through the ADO preview API; the variable lands in the top-level
variables: block next to PS_VERSION.

⚠️ This is a time-boxed workaround, not the fix

It stops working on 2026-09-30. On that date 1ES delists
VanillaWindows2022-1ESPT entirely and CI breaks again, in a way this flag cannot
help with. The image migration still has to happen. There is a comment in
vars.yml saying the same thing next to the variable.

Why I did not just swap the image name

avs-management-windows-2022-1es-image is a pool-local alias, not a generic 1ES
image name. I could not confirm that a 2025 alias exists on our pool, and the
evidence says it does not yet:

1. The alias→image mapping, from build 1357's pre-job log:
   "image": "avs-management-windows-2022-1es-image", "imageResource": ".../galleries/CloudTestGallery/images/VanillaWindows2022-1ESPT/versions/339.0.0"
2. No 2025 alias has ever been used here. I scanned the 60 most recent builds
   across every pipeline in the avs-oss org and extracted every image alias the
   pool actually served. Exactly two exist:
   avs-management-ubuntu-22.04-1es-image and avs-management-windows-2022-1es-image.
3. The pool resource is unreadable from here. It lives in subscription
   f3841f54-1cbc-495c-9914-f6d57d1e6859, which returns
   ERROR: Subscription 'f3841f54-...' not found.
4. No sibling repo has migrated. ADO code search in msazure/One returns 0 hits
   for both avs-management-1es-hosted-pool and avs-management-windows.
5. The 1ES doc says the pool owner must act first. From
   https://aka.ms/1espt/vanillawindows2022 — "If you have your own dedicated pool,
   follow these instructions to add a new image to the pool, and switch pipelines to
   use the new image." The 2025 image has to be added to
   avs-management-1es-hosted-pool before any pipeline can name it.

A wrong alias is not a cheap mistake. The image: value compiles into an agent
demand — ImageOverride -equals <alias> — and template expansion does not
validate it. I checked: expanding with the string definitely-not-a-real-image-xyz
succeeds. An alias no agent satisfies means jobs sit unscheduled rather than
failing fast. So guessing was not worth the risk.

Follow-up needed: someone with access to subscription
f3841f54-1cbc-495c-9914-f6d57d1e6859 adds a Windows 2025 image to
avs-management-1es-hosted-pool. Once the alias exists, point the three entries
above at it and delete this variable.

Supply-chain note

Risk: low, but not zero, and it is worth stating precisely.

This change does not alter build-pool image provenance. It keeps us on
VanillaWindows2022-1ESPT, the same first-party 1ES/CloudTest gallery image we are
running today. No new image, no new publisher, no new source of build inputs. The
supply-chain surface is unchanged.

The real risk is the one the deprecation exists to close: the Windows Server 2022
base image ships .NET 6, which is end of life and no longer receiving patches (since
2026-06-09), and it generates S360 vulnerability items. This PR knowingly accepts
that exposure for a bounded window so two blocked PRs can land. It does not reduce
it, and it expires on 2026-09-30. The migration is the fix.

CI config only. No module, test, or product code touched.

Refs #419, #420