Fail CI if pixi.lock changes without pyproject.toml changes

[chrisburr]

Feature Description

A CI check that fails when a PR modifies pixi.lock but does not modify any dependency source (pyproject.toml, and any other manifest pixi resolves from). The intent is to catch unintentional lockfile changes — notably the v7→v6 format churn from contributors running mismatched local pixi versions — before they reach main.

The check must exempt legitimate lock-only changes, of which there are two kinds:

1. Renovate lockFileMaintenance PRs (e.g. chore(deps): lock file maintenance #898) — automated, scheduled, and lock-only by design. Exempt these deterministically via the bot author (renovate[bot]), the renovate/** branch prefix, or the chore(deps): lock file maintenance title — no human action required.
2. Deliberate manual lock updates by a developer — covered by an explicit, visible marker (a label such as deps: intentional-lock-change).

Renovate's normal dependency bumps also edit pyproject.toml and therefore pass the check without special handling; only lockFileMaintenance needs the exemption.

Definition of Done

• A CI job fails when pixi.lock changes in a PR with no change to dependency declarations.
• The job passes when both change together, or when neither changes.
• Renovate lockFileMaintenance PRs (e.g. chore(deps): lock file maintenance #898) pass without any manual intervention.
• A documented, low-friction override exists for manual intentional lock-only updates.
• The failure message tells the contributor what to do (regenerate with the pinned pixi version, or apply the override).
• Verified against: an accidental change is blocked; a paired manifest+lock change passes; a Renovate lock-maintenance PR passes.

Related Issues

• Must not break the existing Renovate lockFileMaintenance workflow — example PR: chore(deps): lock file maintenance #898.

[aldbr]

ddev: we should bump pixi version in the repo also (prcommit approach is probably not possible given that it would need to skip only for renovate)