Harden the publishing chain against tag/sibling-ref skew

[bdbarnett]

publishing-v7 shipped a macOS wheel matrix that never ran: the top-level reusable-publish-release-packages.yml pins its sibling workflows by tag (@publishing-v6 at the time), so the v7 tag's own wheel-builder file was unreferenced. audioif v0.1.0 burned its tag on the resulting 16-vs-21 wheel-count failure (run 33392558969). publishing-v8 fixed it by bumping all four internal refs in lockstep — but the failure class remains.

Two hardening options, either or both:

1. Nested local references. Replace the internal PyDevices/.github/.github/workflows/X.yml@publishing-vN calls with ./.github/workflows/X.yml — nested reusable workflows called by local path resolve at the caller's own ref, so a tag is self-consistent by construction and cutting publishing-vN+1 becomes a tag with zero ref edits. (Verify GitHub's nested-local support meets our permission/secret inheritance needs before switching.)
2. Self-asserting matrix. The wheel-builder should assert its own expected cell count (or the reusable workflow derive expected-wheel-count from the matrix × python-versions) instead of trusting the caller's literal — a consumer that re-pins without updating its count currently gets either a silent shortfall (count unchanged) or a burned tag (count raised, as audioif proved).

Origin: audioif 0.1.0 release failure, 2026-08-31.