fix(ci): install from uv.lock via uv sync to stop cold-cache e2e timeouts

[keli-wen]

Summary

The dependency-install step used uv pip install -e ., which ignores the tracked uv.lock and re-resolves the whole dependency graph on every run. On the warm ci.yml cache this is fast (~80s), but the path-filtered/scheduled e2e.yml jobs run rarely, so their uv cache is usually evicted (GitHub drops caches after 7 days of no access). On that cold cache, resolution alone took ~6m — probing sdist metadata and backtracking across the 200+ package tree — and the news job's 10-minute timeout cancelled the install before it finished, failing e2e on otherwise-green PRs (for example the run on #124).

This switches every job to uv sync --frozen (CI adds --extra dev), which reads the exact pins from uv.lock and skips resolution entirely, and keys the setup-uv cache on uv.lock instead of pyproject.toml so the cache invalidates on the resolved set rather than the source manifest. Cold-cache installs now only download the locked wheels, landing well under the job timeouts; warm CI installs also drop the redundant re-resolution.

No smoke-test behavior, network dependency, or public API changes — this is install mechanics only.

Related Issue

No tracked issue; the failing e2e install surfaced while validating #124. Root cause and fix are described above.

Verification

• bash scripts/verify.sh — 405 passed, 85.66% coverage, verify loop passed.
• uv sync --dry-run and uv sync --dry-run --extra dev both resolve against the committed uv.lock locally, confirming the runtime and dev sets and the dev extra.
• The real cold-cache timing is confirmed by re-running the affected e2e job after merge.

Checklist

• The title uses English Conventional Commit format: type(scope): summary.
• The related issue or design discussion is linked when applicable.
• bash scripts/verify.sh passes.
• Every applicable live-network component smoke test passes, or this PR states why none applies — none applies; this changes dependency install only, not smoke-test or network behavior.
• Public behavior has focused tests, an example, and documentation where applicable — not applicable; CI-workflow-only change with no public surface.
• The PR is complete, small, and contains no unrelated changes.