The publishing chain calls its own siblings by local path

[bdbarnett]

Fixes #26 (option 1, nested local references).

The four internal PyDevices/.github/.github/workflows/X.yml@publishing-v8
calls in reusable-publish-release-packages.yml become
./.github/workflows/X.yml.

The failure class is live, not historical. publishing-v9 exists and is
already in use (audiodsp calls reusable-synchronize-mip-package.yml@publishing-v9),
and v9's own copy of this file still names @publishing-v8. So a consumer
calling the chain at v9 today gets v8's builders. What that currently costs is
only a setup-java@v5→v6 bump that never takes effect — benign this time.
publishing-v7 was the same mistake with teeth: a macOS wheel matrix that never
ran, and audioif v0.1.0's burned tag.

What I verified before changing anything

The issue asks to "verify GitHub's nested-local support" first, and this
repository's CI only lints YAML — it would go green whether or not the chain
still works. Published guidance is contradictory: several community threads
state that a ./ reference inside a reusable workflow resolves against the
calling repository, which would make this change break every release in
the org, silently, at the next tag.

So I ran it. A throwaway probe reusable workflow in this repository, tagged,
calling a sibling by ./; called from PyDevices.github.io, which has no
workflows of its own — so a reference resolving against the caller could not
possibly have found the file.

✓ call / outer in 2s
✓ call / nested-local / inner in 3s

PROBE_INNER_REACHED
inner reached from: PyDevices/PyDevices.github.io ... @refs/heads/probe/nested-local-ref

The nested job ran. ./ resolves against the repository and ref of the file
that contains the uses:, so a tag is self-consistent by construction. A
second run confirmed the same with secrets: inherit on the ./ call — the
shape request-mip-publication uses. The probe branches and tags are deleted.

What I did not prove: that a secret's value arrives through the nested
local call. Checking that needs either a throwaway repository secret or
reading an existing one, and both were outside what I'm permitted to do here.
The secrets: inherit line itself is unchanged by this PR — only the uses:
ref moved — and request-mip-publication is the single call site that takes
any secret. It is the thing to watch on the first release after the next tag:
if the App token fails to mint there, this is why.

Also relevant: all nine publishing-v* tags are lightweight, not annotated,
which rules out the annotated-tag resolution bug reported in community
discussion #48693.

actionlint clean; the existing test suite passes.

Live only at the next publishing-vN tag. Consumers pin @publishing-v6,
@publishing-v8 and @publishing-v9, so nothing changes for them until a tag
is cut — which is not mine to do. Cutting it is the point of the change: from
that tag on, it is a tag with zero ref edits.