bench iter8b: cache fastled/.venv across runs (#112) — uv_sync 22s → <5s on warm #239

Sub-issue of #112 (iter8 candidate 2).

Hypothesis

uv_sync is consistently the second-largest phase in the iter7 timing:

The warm tarball packs ~/.fbuild, ~/.fastled/global_cache, fastled/.build/pio/<board>, and ${ZCCACHE_CACHE_DIR} — but not fastled/.venv. So every warm run still pays the full 22s to download + install fbuild + dependencies into a fresh virtual environment.

fastled/.venv after uv sync is typically 200–400 MB and contains: a Python interpreter symlink, pip/uv metadata, and the resolved package tree. Pack it into the same tarball and uv sync becomes a no-op (lockfile match → instantly resolved).

Plan

1. Add \$GITHUB_WORKSPACE/fastled/.venv to the paths array in the "Phase - pack cache tarball" step of .github/workflows/benchmark.yml.
2. The warm-restore step already tar -xPfs with absolute paths, so the venv will materialize at the expected fastled/.venv location after restore.
3. In the "Phase - uv sync FastLED venv" step, run uv sync anyway — if the lockfile matches the restored venv, uv sync is sub-second. If FastLED's pyproject.toml or lockfile changed between the artifact-source run and now, uv sync will reconcile correctly.
4. Watch for .venv content that doesn't survive tarballing: symlinks to system Python, absolute-path shebangs, RECORD file hashes. On ubuntu-latest with the same actions/setup-python version pinned (3.12), this should be stable.

Edge cases to handle

• actions/setup-python interpreter path changes between runs. Mitigation: pack with --dereference so the venv carries its own Python bin copy, or rerun uv sync --reinstall-package python defensively before the compile step.
• pyproject.toml / uv.lock drift on FastLED master between runs. The current workflow already runs uv sync after restore, so dependency-set changes are reconciled — venv cache becomes a head-start, not a hard requirement.
• Tarball bloat. Current artifact is ~64 MB compressed. Adding a venv may push it to 100–150 MB. Well below actions/upload-artifact's practical limits.

Expected savings

Acceptance

• Warm uv_sync ≤ 5s.
• No new failure mode in the compile phase from a stale venv (run the same FastLED ref before/after to confirm reproducibility).
• Tarball compressed size ≤ 200 MB.
• Cold-run timings unchanged vs iter7 (this is a warm-only optimization).

Out of scope

• Caching uv's global package cache. astral-sh/setup-uv@v6 already has enable-cache: true set in the workflow, but that only restores uv's package cache, not the resolved venv — so uv sync still has to materialize the tree per run. Layering the venv on top eliminates the materialization cost itself.

Related

• [META] Fastest possible FastLED examples CI rebuild — profile + benchmark #112 — meta tracker
• Iter7 baseline (last comment on [META] Fastest possible FastLED examples CI rebuild — profile + benchmark #112)
• Independent of iter8a (parallel compile), both stack.