Disentangle PR-induced and base-maintenance Pixi lockfile updates

[rwgk]

Problem statement

The PR-triggered Pixi lockfile freshness check currently treats every stale lockfile as though the pull request introduced the staleness. Its remediation therefore tells the PR author to regenerate and commit the lockfile.

That is correct when the PR changes a manifest, source-package metadata, or another lock input. It is misleading when the same lockfile is already stale on the PR's base commit—for example, because compatible packages appeared in an external package index or an earlier change on the default branch did not refresh its lockfiles. In that case, regenerating the lockfile in an otherwise unrelated feature PR mixes general dependency maintenance into the feature change.

For example, PR #2922 changed setuptools-scm configuration but no lockfiles. Its freshness check reported benchmarks/cuda_core as stale because Pixi selected newer cuda-bindings and cuda-pathfinder packages. Running the same pinned Pixi version on both the PR base and PR head produced the same repair, byte for byte: the update was already needed on the base and belonged in the general maintenance refresh PR #2921, not in #2922.

The check should distinguish these cases and give remediation that preserves a focused PR while retaining the lockfile freshness merge gate.

Smarter freshness check

For pull_request runs:

1. Check the candidate merge tree as today.
2. If a workspace fails, check that workspace at github.event.pull_request.base.sha with the same pinned Pixi version and, as far as practical, the same cache and package-index snapshot.
3. Record the original and post-check lockfile blob hashes for both trees.
4. Classify each failure:

Base result	Candidate result	Classification	Remediation
Fresh	Stale	PR-induced	Regenerate and commit the affected lockfile in this PR.
Stale with the same original and repaired blobs	Stale with the same original and repaired blobs	Base maintenance	Do not add the refresh to this PR. Merge the maintenance refresh, then update the branch and rerun CI.
Stale, but either blob differs	Stale	Mixed or ambiguous	Refresh the base first, update the branch, then address any remaining PR-specific change.

Comparing blobs, rather than only exit statuses, prevents a PR-specific lockfile change from being misclassified merely because the base also happens to be stale.

For base-maintenance failures, the annotation and job summary should state clearly that the condition was not introduced by the PR and link to:

• the open all-workspace refresh PR, when one exists; or
• the Pixi lockfile refresh workflow.

The required aggregate check should remain failing until the maintenance refresh reaches the PR's candidate tree. This preserves merge gating without encouraging unrelated lockfile churn in the feature PR.

For push and workflow_dispatch runs, retain the current strict behavior because there is no PR base to compare. Timeouts and other operational errors should continue to fail distinctly rather than being classified as staleness.

Completion criteria

• PR-induced, base-maintenance, and mixed/ambiguous failures receive distinct diagnostics and remediation.
• Base-maintenance attribution requires matching original and repaired lockfile blobs.
• General maintenance updates are not presented as changes to commit in an unrelated feature PR.
• The required aggregate freshness gate remains strict.
• Push and manual runs retain their current strict behavior.
• Classification logic is covered by focused tests.