[bdbarnett]

When GitHub never delivers the push event for a release merge, the tag and Release don't get made. audiodsp carried its own workflow_dispatch fallback for that; this moves it into the shared workflow so every repository can use it.

A caller that also triggers on workflow_dispatch and passes two optional inputs through gets a manual path:

• release: a version (X.Y.Z[{a|b|rc}N|.devN]), a merge SHA, or blank for VERSION as it stands on the default branch.
• dry-run: say what would be tagged and tag nothing.

It tags the commit on the default branch that brought VERSION to that version, never an arbitrary one. It refuses a placeholder or anything outside the version grammar, a SHA that isn't that commit or isn't on the default branch, and a run from any other branch. It does nothing if the tag exists. The push path is unchanged, and callers that don't dispatch need no change; the caller shape is in the header comment of the workflow and in docs/publishing-automation.md.

Checked: 27 tests in tests/test_tag_on_release_merge.py run the workflow's own shell in throwaway git repos (15 new, covering each accept and refuse case above); ruff, shellcheck on both steps and a YAML parse are clean. Removing the commit-match check or the version-grammar check makes the tests fail. I could not run actionlint locally (the download was blocked), so CI's actionlint job is the first run of it.

Not proven until a tag is cut and a repo calls the new version: the workflow_call input wiring, the workflow_dispatch event reaching the reusable, and the App-token gh release create on this path. A dry run from a consumer repo after that is the first check.