ci: move checkout and setup-python off Node 20 before the fallback goes

[LukasWodka]

Part of the fleet-wide sweep tracked in tracebloc/backend#2004. Sibling of tracebloc/backend#2005, which is green.

Why

Every job in this repo emits:

Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24.

The forced run is a temporary GitHub fallback. When it is withdrawn, every job using these two actions fails. Same defect class as tracebloc/backend#1816, which moved add-to-project off using: node20.

Measured, from each tag's own action.yml

Read runs.using at the tag rather than trusting release prose:

action	tag	using:
checkout	v4.x (was pinned here)	node20
checkout	v5.1.0 / v6.1.0 / v7.0.1	node24
setup-python	v5.x (was pinned here)	node20
setup-python	v6.0.0 / v6.3.0 / v7.0.0	node24

checkout needs v5+, setup-python needs v6+. Note v4.4.0 was published 2026-07-20 alongside v5.1.0/v6.1.0/v7.0.1 — the v4 line is still maintained but stays on node20, so waiting does not fix this.

Why latest rather than the minimal v5/v6 hop

• cli already ran exactly these two SHAs before this sweep, so latest is proven in the org, and the fleet converges on one pin per action instead of gaining a third variant.
• One bump instead of two.
• Neither v7 breaking change applies — checked per repo, not assumed:
  • setup-python v7 drops the pip-install input → unused anywhere in the org.
  • checkout v7 blocks fork-PR checkout under pull_request_target/workflow_run → every workflow's resolved triggers were parsed as YAML, not grepped, so a comment naming a trigger cannot be mistaken for using one. No workflow in this repo pairs those triggers with a checkout.

This also normalises the pin comments: some lines carried a bare # v4, which is a mutable major alias in comment form rather than the full-semver convention.

Verification

• git diff -U0 inspected: only uses: lines changed, in either direction
• Every workflow in the repo still parses as YAML
• Anchor asserted: no occurrence of any old SHA survives under .github/workflows/
• CI on this PR is the real proof for the two actions in scope: checkout and setup-python no longer appear in the run's Node 20 deprecation annotation, with no other behavioural change.
• The annotation itself does not disappear, and should not be read as the pass/fail signal. This repo still pins 5 other action(s) whose action.yml declares using: node20 (azure/setup-helm ×5, actions/upload-artifact ×2, softprops/action-gh-release ×2, actions/download-artifact ×1, actions/stale ×1) — out of scope here, measured the same way (read runs.using at the pinned SHA).
• In caller repos the quality / * jobs come from code-quality.yml@main, so their annotation also keeps naming the old checkout pin until .github promotes develop → main. That is a sequencing artefact of the reusable, not a defect in this PR.

Ordering

No sequencing constraint. caller-drift.py byte-compares only the entries marked copies: in repo-inventory.yml, and there are none fleet-wide — so these PRs may merge in any order, including .github.

Two repo-specific notes

1. Self-hosted runner. windows-e2e.yaml runs runs-on: [self-hosted, windows, nested-virt], and checkout v5+ requires runner ≥ v2.327.1. The API reports total_count: 0 registered runners at both repo and org level, so nothing is live to break today — but confirm the agent version if that runner is ever re-registered. Flagging rather than assuming. (installer-tests.yaml only mentions self-hosted in a comment; every job in it is ubuntu-latest.)

2. Duplicate pins collapsed. This repo carried two different pins of checkout — v4.4.0 and v4.3.1 — which is drift in its own right. Both now point at one SHA.

---

Note

Low Risk
Pin-only workflow edits with no application or release logic changes; main caveat is self-hosted Windows runners needing a recent actions runner version for checkout v7.

Overview
Fleet-wide pin update: every actions/checkout step under .github/workflows/ now uses the same SHA (3d3c42e5…, v7.0.1) instead of mixed v4 / v4.4.0 pins.

This is part of the org sweep to move off Node 20 actions before GitHub drops the forced Node 24 fallback. Checkout v4 runs on node20; v7 runs on node24. Only uses: lines change — no job logic, triggers, or step inputs were touched.

Workflows touched include helm CI, installer tests, release chart, drift/digest guards, k3s-cuda build, standard checks, and the self-hosted windows-e2e job (note: checkout v5+ needs runner ≥ v2.327.1 if that runner is re-enabled).

^{Reviewed by Cursor Bugbot for commit 12abf5d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[LukasWodka]

E2E auth-proxy (squid) went red, then green on a --failed rerun — recording it, because the signal was misleading

First run of this branch failed §4 with:

✖ App pod WITH the ingestion proxy env did NOT tunnel through the squid — ingestion-style backend egress is not proxied (the #119 bug).

Everything about the surrounding evidence pointed at a real regression, and it wasn't one. Worth writing down, because the next person will read the same signal:

• The job had 11 consecutive successes earlier the same day — on develop, main, feature/560, feature/564, fix/1964-… — including a develop run 14 minutes before mine.
• The only failure in that window was on this branch.

"Green everywhere except your branch" normally means you broke it. Here it could not: this PR changes 26 uses: lines pinning actions/checkout, and nothing in a checkout SHA can decide whether an app pod tunnels its egress through squid. The diagnostic also showed the squid pod 1/1 Running with endpoints bound, so the usual Service-readiness race did not obviously apply either — which made it look more like a real failure, not less.

gh run rerun --failed on the same commit: completed success, no code change. So it is non-deterministic, and the low background rate is what makes it dangerous rather than harmless — a flake that fires once in a dozen runs is one that gets attributed to whatever PR it lands on.

The PR is now 45 pass / 0 fail. Nothing was changed to make it pass.

Flagging for whoever owns the flaky-job work: this occurrence is a data point that §4 can fail with the proxy pod fully ready, so a Service-readiness race may not be the whole story.