CI: enforce uv.lock / pyproject.toml consistency with --locked

## Problem

CI (`.github/workflows/CI.yml`) installs deps with plain `uv sync --group dev`, which **re-resolves and silently updates** the lockfile in the ephemeral runner. It never runs `uv sync --locked` (or `uv lock --locked`), so a `pyproject.toml` whose floor exceeds the committed `uv.lock` version passes CI green while leaving `uv.lock` inconsistent on `main`.

This was just observed: Dependabot PRs #261 (plotly), #263 (ibis-framework), #264 (pyarrow) raised lower bounds **above** the locked versions and touched only `pyproject.toml`. Each was CLEAN/MERGEABLE with green CI. Consolidated and lock-synced in #271, but nothing prevents recurrence.

## Class shape

Recurs on every future Dependabot floor bump that exceeds the lock. The lockfile is durable state; drift on `main` means a fresh `uv sync` silently rewrites `uv.lock` and dirties the tree.

## Proposed guard (recommend both)

1. **Add a consistency step** to the `lint` job, e.g. `uv lock --locked` — fails fast when `pyproject.toml` and `uv.lock` disagree. Lowest friction; catches drift.
2. **Configure Dependabot to manage `uv.lock`** so floor bumps arrive lock-synced and never drift in the first place. Fixes at source; complements #1.

Adding #1 means raw pyproject-only Dependabot PRs start failing CI until the lock is synced — the intended forcing function.

## Acceptance
- [ ] CI fails when `uv.lock` is inconsistent with `pyproject.toml`
- [ ] (optional) Dependabot config updates `uv.lock` alongside `pyproject.toml`

Start with .github/workflows/CI.yml and inspect the lint job's current uv sync command. Then inspect the repository's Dependabot configuration to determine whether uv.lock can be updated with pyproject.toml. Done means CI fails for inconsistent files, with the optional Dependabot update configured if supported.

Written by the indexing model from the issue text.