CI efficiency: avoid the redundant fixture rebuild after fixture-changing merges

GitHub Actions caches are branch-scoped: a fixture cache written by a PR's CI is invisible to main. So every fixture-changing merge currently costs one redundant rebuild — the merge commit's Sphinx run cache-misses and rebuilds the fixture (~15 min of runner time), producing a fixture that is immediately superseded by the deliberate post-merge refresh (whose artifact is what baselines are regenerated against).

Observed on the PR #9 merge: the PR built+cached the fixture on its branch scope, then main's Sphinx run rebuilt it from scratch anyway, then the refresh workflow rebuilt it a third time as the canonical copy.

Options, roughly in order of appeal:

1. Seed from the merged PR's artifact. A workflow_run-triggered job (or a step in the refresh workflow) that downloads the merged PR's sienna-v4-fixture artifact and writes it to main's cache under the same key — no rebuild at all, and baselines stay consistent with what the PR actually tested against. Wrinkle: artifact retention (7 days) and locating the right run from the merge commit.
2. Make Sphinx defer instead of rebuild. When the fixture cache is cold, skip the gallery build (docs deploy without gallery or don't deploy) and let the post-refresh rebuild produce the full docs. Wrinkle: docs lag the merge until someone runs the refresh.
3. Auto-trigger the refresh on fixture-changing merges (workflow_run / push-path filter) so at least the redundant build and the canonical build collapse into one deliberate sequence. Wrinkle: reintroduces an automatic rebuild path, which the fail-fast design deliberately avoids — would need the baseline-regen step to stay human.

Context: the fail-fast design in tests.yml exists because implicit rebuild-on-miss caused silent fixture/baseline drift (see the workflow comments). Any change here must preserve the invariant that the cached fixture and committed baselines always come from the same build.

Fixture-changing merges are rare (next candidates: #10 stressed fixture, #13 horizon change), so this is efficiency polish, not urgency.

Start with the fail-fast design and workflow comments in tests.yml, then inspect the post-merge refresh workflow and its sienna-v4-fixture artifact handling. Compare the proposed options and verify that the cached fixture and committed baselines still come from the same build while eliminating the redundant rebuild after fixture-changing merges.