Feature/migrate to uv

[bsisduck]

Description

Hi!

I saw the comment in Issue #293 suggesting move to uv, so I decided to jump in and migrate the project.
To be honest, the speed difference is night and day. Running setup locally is now almost instantaneous (~2.2s vs ~99s). I've set everything up so it works out of the box CI is faster, Docker is cleaner, and local dev is much smoother.

What I changed:

• Added uv.lock: Now everyone (and CI) gets the exact same package versions. No more "it works on my machine" weirdness.
• Updated CI: Switched GitHub Actions to use uv with caching. It's noticeably faster.
• Cleaned up setup: Updated README.md and CONTRIBUTING.md with simple commands to get started.

Does it actually help?
Yeah, big time. I ran some benchmarks:

• Local setup (warm cache): Drops from ~99s to ~2.2s. 🚀
• Integrity: I added a script to make sure we didn't break any imports, and everything looks green.

Fixes #293

How Has This Been Tested?

I didn't want to break anything, so I ran a few checks:

1. Ran the full test suite: Used uv to run pytest, everything passed.
2. Smoke tested the repo: Wrote a script (verify_integrity.py) that checks if every single file imports correctly. It all passed.
3. CI: Let the GitHub Actions run do its thing, all green.

Checklist:

• I have read and acknowledged Google's Open Source Code of conduct.
• I have read the Contributing page.
• I discussed/saw the issue (uv as default in docs #293) and thought I'd help out.
• I updated the docs (README.md), CONTRIBUTING.md) so people know how to use the new tools.
• I added some verify scripts to be safe.
• Check code style? Yep, ran pylint.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

❌ Infrastructure File Protection

This PR modifies protected infrastructure files:

• .github/workflows/ci.yaml (61 changes)
• CONTRIBUTING.md (8 changes)
• Dockerfile (5 changes)
• tox.ini (5 changes)

Only repository maintainers are allowed to modify infrastructure files (including .github/, build configuration, and repository documentation).

Note: If these are only formatting changes, please:

1. Revert changes to .github/ files
2. Use ./autoformat.sh to format only source code directories
3. Avoid running formatters on infrastructure files

If structural changes are necessary:

1. Open an issue describing the needed infrastructure changes
2. A maintainer will review and implement the changes if approved

For more information, see our Contributing Guidelines.

[github-actions]

❌ Infrastructure File Protection

This PR modifies protected infrastructure files:

• .github/workflows/ci.yaml (61 changes)
• .pylintrc (4 changes)
• CONTRIBUTING.md (8 changes)
• Dockerfile (5 changes)
• tox.ini (5 changes)

Only repository maintainers are allowed to modify infrastructure files (including .github/, build configuration, and repository documentation).

Note: If these are only formatting changes, please:

1. Revert changes to .github/ files
2. Use ./autoformat.sh to format only source code directories
3. Avoid running formatters on infrastructure files

If structural changes are necessary:

1. Open an issue describing the needed infrastructure changes
2. A maintainer will review and implement the changes if approved

For more information, see our Contributing Guidelines.

[github-actions]

❌ Infrastructure File Protection

This PR modifies protected infrastructure files:

• .github/workflows/ci.yaml (61 changes)
• .pylintrc (4 changes)
• CONTRIBUTING.md (8 changes)
• Dockerfile (5 changes)
• tox.ini (5 changes)

Only repository maintainers are allowed to modify infrastructure files (including .github/, build configuration, and repository documentation).

Note: If these are only formatting changes, please:

1. Revert changes to .github/ files
2. Use ./autoformat.sh to format only source code directories
3. Avoid running formatters on infrastructure files

If structural changes are necessary:

1. Open an issue describing the needed infrastructure changes
2. A maintainer will review and implement the changes if approved

For more information, see our Contributing Guidelines.