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.

[bdbarnett]

Option 1 is up as #44, and the nested-local behaviour is verified against real runs rather than taken from the docs (community guidance on this is contradictory, and this repo's CI only lints YAML so it would go green either way). A ./ reference resolves against the repository and ref of the file containing it, so a tag becomes self-consistent by construction.

Two things worth recording separately from the PR:

The skew is live at publishing-v9, not just history. v9 exists and is in use — audiodsp calls reusable-synchronize-mip-package.yml@publishing-v9 — but v9's own reusable-publish-release-packages.yml still names @publishing-v8 for all four siblings. A consumer calling the chain at v9 gets v8's builders. Today that costs only a setup-java@v5→v6 bump that never takes effect, so nothing is broken; but it is the same mistake as v7, made again, three tags later. #44 does not fix v9 — it takes effect at the next tag.

Option 2 (the self-asserting matrix) is untouched and still open on its merits. It is the half that would have caught v7 at the time: expected-wheel-count is still a literal the caller passes, so a consumer that re-pins without updating it gets either a silent shortfall or a burned tag. #44 removes the way the skew arises; it does not add the assertion that would catch it if it arose another way. Happy to leave this issue open for that, or split it.