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 handles this: it 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 and demonstrates the result end to end. Unlike that PR this one is config-only, with no self-hosted workflow: a Renovate maintainer has confirmed that Mend will add pixi to allowedUnsafeExecutions on the hosted Renovate App, so pixi.lock refreshes will start working here with no further change once that lands. uv.lock is not gated and works immediately, as does everything else Renovate manages.

• Adds renovate.json, porting the existing dependabot configuration.
• Removes .github/dependabot.yml to disable dependabot.
• Adds a commitlint ignore pattern for Renovate PR descriptions in pr_title.yml. The dependabot patterns stay for now, because dependabot PRs opened before this change are still open and would start failing the PR title check without them.

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

Verified locally with renovate --platform=local: pep621 reports both uv.lock and pixi.lock as lock files for pyproject.toml, dockerfile picks up the devcontainer image, and github-actions covers the workflows — 59 dependencies in total, with no repository problems reported.

Three choices worth a look:

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. This is the one dependabot group that has to be carried over exactly.

The pre-commit manager is deliberately left disabled. .pre-commit-config.yaml has a ci: block, so pre-commit.ci already autoupdates the hooks with chore(deps): [pre-commit.ci] autoupdate. Renovate's pre-commit manager is off by default and enabling it would duplicate that work. The spec repo does enable it, because it has no pre-commit.ci.

:semanticCommitTypeAll(chore) is belt-and-braces. config:recommended pulls in :semanticPrefixFixDepsChoreOthers, which assigns fix to dependencies whose depType is dependencies, and package rules override top-level config. Our pep621 dependencies come through as project.dependencies and dependency-groups, so nothing currently matches that rule and dependency PRs would be chore regardless. Pinning it explicitly keeps that true if the dependency layout or the preset changes later, which matters here because fix would make semantic-release cut a patch release from a dependency bump.

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. lockFileMaintenance covers the rest by refreshing the transitive pins in both lock files weekly.