feat: Add kubernetes.azure.com/scalesetpriority to WellKnownLabels

[matthchr]

How was this change tested?

• Unit test
• E2E test: https://github.com/Azure/karpenter-provider-azure/actions/runs/20793223642

Does this change impact docs?

• Yes, PR includes docs updates
• Yes, issue opened: #
• No

Release Note

Add scheduling support for the kubernetes.azure.com/scalesetpriority label.

[tallaxes]

Let's rerun E2E?

[matthchr]

kicked off E2E, will wait til it passes.

[matthchr]

Ok so E2E passed, except...
Initial run had:
suite-Drift

should respect budgets for non-empty replace drift

Failed, due to:

  STEP: checking the final count of nodes and nodeclaims - /home/runner/work/karpenter-provider-azure/karpenter-provider-azure/test/suites/drift/suite_test.go:296 @ 01/07/26 19:24:29.587
  [FAILED] Expected
      <int>: 6
  to be ==
      <int>: 5
  In [It] at: /home/runner/work/karpenter-provider-azure/karpenter-provider-azure/test/suites/drift/suite_test.go:297 @ 01/07/26 19:24:29.587

Which I think is a flake, as well as consolidation test suite interrupted and suite-scheduling

[FAIL] Scheduling Provisioning [It] should provision a node for naked pods

This one looked like a pod failed when it was scheduled to the node:

[CREATED/UPDATED 2026-01-07T19:34:19Z] POD default/trackberry-51-v5kkaxatsr provisionable=false phase=Failed nodename=aks-racersheer-49-d7fykcz147-xsc2s owner=[]v1.OwnerReference(nil) [bardwalnut-52-dxqknnz1tw restarts=0]

but it passed on retry so I am wondering if it was something like container pull throttling... not an issue with this change.

[matthchr]

Overall I think this LGTM for E2E pass now (see the link). Only failing suite is consolidation which we know has some flakes atm.