Root cause of the simultaneous lane-shas failures on PRs #46 and #47:
workflows installed with unlocked 'uv pip install -e .' against floor-only
specs (numpy>=1.26, ...) while the repo maintains uv.lock — so a PyPI
release landing between runs shifts the runner's resolved set, and the
byte-exact lane SHA pins move with it. Timeline: main lane run green at
23:40Z, both PR runs (diffs no lane executes) red after 00:02Z; the
identical trees verify 9/9 locally against the locked venv, and
'uv lock --check' is clean.
All six workflows now 'uv sync --locked' (--extra dev where [dev] was
installed) — CI tests the locked universe, so lane pins can only move when
code moves. Locked-sync also fails loudly on a stale lock instead of
silently resolving fresh.
Self-validating: this PR's own lane-shas run uses this branch's workflow.
[Verification]: smoke suite passed locally (175 passed); lane repro on the
failing PRs' tree: 9/9 pinned SHAs; uv lock --check clean.
Unblock the single Act runner: post-merge full-pytest runs the fast
marker (not quarantine and not slow); full non-quarantine suite moves
to nightly + workflow_dispatch. lane-shas uses job-level path detection
so docs-only PRs skip green without hanging required checks. Sync
smoke/conftest/docs CI contracts to the PR/main/nightly policy.
