fix(fixtures): bind synthetic provenance to the fixture byte determinants

[abrichr]

What this changes

synthetic-provenance.json recorded lock_path and lock_sha256, a sha256 of the entire uv.lock, and tests/test_synthetic_fixtures.py asserted it. This drops both fields and bumps the provenance schema to v2.

Why

The lock hash does not determine the fixture bytes. The generator reads four things: the source spec, its own source, the repository's writer code, and the SQLite and SQLAlchemy versions. All four are already pinned precisely. The spec and the generator are recorded by sha256 and asserted against the files. The two library versions are recorded by value, and require_exact_builder() raises if the running interpreter does not match them.

Worse, the coupling was self-referential. The lock hash went into the provenance, the provenance is embedded in the recording config, and the config is inside the sealed database. So a lock rewrite changed the sealed binary fixtures by definition, whether or not it touched anything the generator reads.

That is not hypothetical. #96 adds a linux extra holding a single platform-gated PyGObject dependency. uv sync re-locks, and the result:

• adds two Linux-only wheels, pygobject and pycairo
• migrates the lock file format from version = 1 to revision = 3, about 2,195 lines changed
• changes zero resolved versions of anything already locked, SQLAlchemy included

I checked the causality directly rather than reasoning about it. With the environment resolved and installed from the new lock, and the recorded hash held at the old value, all five generated artifacts in both fixtures regenerate byte for byte identical. The lock's contents contributed nothing. Only the recorded hash did.

Every dependency PR from here on would have had to rewrite two sealed binary fixtures for no reason. Note also that .github/workflows/test.yml pins astral-sh/setup-uv@v7 at version: "latest", so the lock format tracks whatever uv ships that week. The fixture seal should not.

What still catches a real change

check_generated() is untouched and stays the authority. It regenerates all five artifacts into a temp directory and compares every byte. It runs on the 3.12 lane, where the SQLite and SQLAlchemy versions match, so it does the real comparison there rather than the guard-fires check.

A dependency change that genuinely moves the bytes fails that comparison with generated bytes are stale. A dependency change that does not move the bytes now passes, which is the correct outcome and the point of the change.

Two tests were added so this is asserted rather than assumed:

• test_a_changed_source_spec_makes_the_committed_fixtures_stale moves one action coordinate by a single pixel in a copy of a source spec and requires the byte check to fail.
• test_every_committed_fixture_artifact_is_byte_checked flips one byte in each of the five generated artifacts in turn and requires the byte check to fail each time.

Both skip on a builder that cannot reproduce the committed bytes.

Verification

• pytest tests/ --ignore=tests/test_browser_bridge.py: 611 passed, 13 skipped, locally on Python 3.12.13, SQLite 3.53.1, SQLAlchemy 2.0.52.
• ruff check openadapt_capture/: clean.
• No consumer of the v1 provenance schema exists anywhere else in the workspace.

Fixtures were regenerated with the committed generator, not hand-edited.