ci: switch from dependabot to renovate

[nielspardon]

Dependabot has no pixi support, so pixi.lock is never refreshed when a dependency PR changes pyproject.toml. Because pixi validates the lock file against the manifest, a stale pixi.lock breaks ruff.yml, the workflow that uses pixi. Renovate runs uv lock and pixi lock for the same update, so both lock files stay in step with the manifest.

This mirrors substrait-io/substrait#1075, which makes the same switch for the spec repo. The two configs differ only where the repos differ: the pre-commit manager is enabled there because that repo has no pre-commit.ci, whereas ours is already autoupdated by the ci: block in .pre-commit-config.yaml, and the substrait group and the deps-dev scope rule are specific to this repo.

• Adds renovate.json, porting the existing dependabot configuration.
• Removes .github/dependabot.yml to disable dependabot.
• Holds new releases for 14 days before proposing them (minimumReleaseAge), so a compromised or broken release has time to be caught, following the cooldown advice in https://pixi.prefix.dev/latest/security/#2-exclude-newer.
• Adds a commitlint ignore pattern for Renovate PR descriptions in pr_title.yml. The dependabot patterns stay while chore(deps): bump the substrait group across 1 directory with 3 updates #254 is open, or the PR title check would start failing on it.

How the dependabot configuration maps across

.github/dependabot.yml	renovate.json
github-actions, weekly	auto-detected; lockFileMaintenance runs weekly
uv ecosystem, weekly	pep621 manager, which drives both uv.lock and pixi.lock
substrait group (3 packages)	matchPackageNames, groupName: substrait packages
docker in /.devcontainer	auto-detected by the dockerfile manager
commit-message: {prefix: chore, include: scope}	semanticCommitType: chore + a deps-dev scope rule
no equivalent — we never configured a dependabot cooldown	minimumReleaseAge: 14 days, exempting the substrait group

:semanticCommitTypeAll(chore) in extends is what makes that chore type stick: config:recommended would otherwise assign fix to some dependency updates, and a fix makes semantic-release cut a patch release from a dependency bump.

The substrait group is mandatory rather than cosmetic. version-checks.yml runs check_substrait_package_versions.sh on every PR, which fails unless substrait-protobuf, substrait-antlr and substrait-extensions all report the same version. Ungrouped, Renovate would raise three separate PRs and each one would fail CI.

That group is also exempt from the cooldown, with minimumReleaseAge: null on the same rule. We publish those three packages ourselves, usually right after a spec release, so there is no third-party release for the ecosystem to vet and the cooldown would only delay adopting our own spec bump by two weeks.

What changes about the PRs we receive

Renovate covers ground our dependabot configuration did not, so expect a batch of new PRs on the first run: the conda dependency in [tool.pixi.dependencies], which dependabot's uv ecosystem never looked at, and the pixi-version pinned in our workflows, which Renovate picks up from the prefix-dev/setup-pixi inputs in addition to the action itself.

Dependencies declared as ranges only get a PR once the new version falls outside the range, so a quiet dependency is expected rather than a sign that something is broken — as is a release still inside the 14-day cooldown, which appears on the Dependency Dashboard instead of as a PR. lockFileMaintenance covers the rest by refreshing the transitive pins in both lock files weekly, and Renovate leaves the cooldown out of those updates because the package manager chooses the versions itself. Putting a cooldown on the transitive pins therefore needs pixi's [tool.pixi.workspace] exclude-newer and uv's exclude-newer, a follow-up here and in the spec repo.

[nielspardon]

Decision on #260: it is replaced by this PR, not merged. #260 is Renovate's onboarding PR and carries only the default configuration, so this PR is the vehicle for the config we actually want.

Order matters, so: merge this PR first, then close #260 unmerged. Renovate decides whether a repository is onboarded in onboarding/branch/check.ts, and the config-file check runs before it looks at whether an onboarding PR was closed. So with renovate.json on main, the closed #260 is never consulted and Renovate just runs.

Closing #260 first would instead hit the other path, because there is no config file on main yet: Renovate posts a "Renovate is disabled" comment on #260 and aborts the run with disabled-closed-onboarding until the config lands. That is recoverable rather than harmful — merging this PR clears it — but it puts a misleading comment on a bot PR other maintainers may be watching, for no gain. I have left #260 open for that reason; happy to close it the moment this merges, or now if you would rather clear it from the queue.

This also drops the alternative I raised earlier, of pushing this config into #260's renovate/configure branch to preview the real PR list. That would make the onboarding PR the vehicle, which is the opposite of the decision above. The renovate --platform=local preview in the description covers the same ground.

Two other things while this is in review, both deliberate:

• The dependabot commitlint ignore patterns stay. chore(deps): bump the substrait group across 1 directory with 3 updates #254 is still open and was opened by dependabot, so the PR title check would start failing on it if the patterns went now. They can be dropped in a follow-up once it is closed out.
• exclude-newer in pyproject.toml is not part of this PR. Renovate cannot apply minimumReleaseAge to lockFileMaintenance, so a cooldown on the transitive pins in uv.lock and pixi.lock has to come from pixi's and uv's own exclude-newer. Separate PR, and the spec repo is doing the same thing separately.