Regenerate stale uv.lock and enforce lockfile consistency in CI

Bắt đầu bằng cách so sánh pyproject.toml và src/browserbase/_version.py với metadata của package gốc và các mục dependency trong uv.lock. Chạy uv sync --all-extras bằng uv 0.12.3, xem lại diff của lockfile được tạo ra, đồng thời kiểm tra CONTRIBUTING.md và scripts/bootstrap để nắm workflow dành cho contributor. Được xem là hoàn tất khi lockfile đã commit được đồng bộ hóa và một lần sync sạch không làm thay đổi nó; CI cũng nên kiểm tra lockfile bằng --locked hoặc uv lock --check.

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.