Regenerate stale uv.lock and enforce lockfile consistency in CI

まず、pyproject.toml と src/browserbase/_version.py を、ルートパッケージのメタデータおよび uv.lock の依存関係エントリと比較します。uv 0.12.3 で uv sync --all-extras を実行し、生成された lockfile の差分を確認して、コントリビューターのワークフローについて CONTRIBUTING.md と scripts/bootstrap を確認します。コミットされた lockfile が同期され、クリーンな sync で変更されなければ完了です。CI でも --locked または uv lock --check を使用して lockfile を検証する必要があります。

Description

The committed uv.lock is stale relative to the current project metadata:

• pyproject.toml and src/browserbase/_version.py are at 1.17.0, while the root package entry in uv.lock is still 1.15.0 (uv.lock:229).
• Dev dependencies added in the July 28 tooling migration (playwright, pytest-playwright, python-dotenv, and selenium) are present in pyproject.toml but absent from the committed lockfile's browserbase dev dependency metadata (uv.lock:249-264, uv.lock:286-302).

Reproduction

From a clean checkout:

uv sync --all-extras

git diff -- uv.lock

With uv 0.12.3, this rewrites the root package version and adds the missing dev dependency graph (over 1,000 lockfile lines in the current resolution). Conversely, a frozen install follows the stale graph and does not install the example/E2E dependencies declared by the project.

Expected behavior

The committed lockfile should be synchronized with pyproject.toml, and a clean uv sync --all-extras should not mutate it. CI should ideally check the lockfile with --locked/uv lock --check so future metadata changes cannot drift.

Actual behavior

Normal contributor bootstrap changes a tracked file, while frozen/reproducible installs omit declared development packages.

Why it matters

CONTRIBUTING.md and scripts/bootstrap direct contributors to use uv, and CI also installs from this metadata. Lock drift makes local and CI environments non-reproducible and contributed diffs noisy.