Regenerate stale uv.lock and enforce lockfile consistency in CI

Start by comparing pyproject.toml and src/browserbase/_version.py with the root package metadata and dependency entries in uv.lock. Run uv sync --all-extras with uv 0.12.3, review the resulting lockfile diff, and check CONTRIBUTING.md and scripts/bootstrap for the contributor workflow. Done means the committed lockfile is synchronized and a clean sync does not mutate it; CI should also verify the lockfile with --locked or 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.