feat: add trigger: :workflow_call, neither existing trigger fires for release-please users

[joshrotenberg]

Follow-up to #103. The attach mode works, but neither available trigger actually
fires in the setup it was built for.

The problem

GitHub does not start new workflow runs from events created with the default
GITHUB_TOKEN:

When you use the repository's GITHUB_TOKEN to perform tasks, events
triggered by the GITHUB_TOKEN will not create a new workflow run.

release-please runs as an action and creates both the tag and the GitHub Release
with GITHUB_TOKEN unless explicitly given a PAT. So for a stock release-please
repo:

• trigger: :tag_push — the tag push does not fire on: push: tags
• trigger: :release_published — the release creation does not fire
  on: release: [published]

Both silently never run. Nothing errors; the release just has no binaries.

This bites exactly the audience --attach was added for. hexpm-mcp
(joshrotenberg/hexpm-mcp#68) hit it: release-please.yml calls
googleapis/release-please-action@v5 with no token: input, so no amount of
trigger configuration produces a build.

Existing workaround, and why it is not great

Give release-please a PAT so its events are attributable to a user. That means
a long-lived credential in the repo purely to work around an event-attribution
rule, and it re-triggers every other push-triggered workflow too.

Proposal

trigger: :workflow_call, generating:

on:
  workflow_call:
  workflow_dispatch:

The release-managing workflow then invokes it directly, in the same run, with no
event round-trip and no token games:

  binaries:
    needs: release-please
    if: needs.release-please.outputs.release_created == 'true'
    uses: ./.github/workflows/release.yml
    secrets: inherit

hexpm-mcp already uses this shape for its Fly deploy: deploy.yml is
workflow_call + workflow_dispatch, and release-please.yml calls it via
uses:. Adding it as a tinfoil trigger would let the binaries job sit alongside
the existing publish and deploy jobs instead of hoping an event propagates.

Notes:

• --attach is still the right publish mode here: release-please created the
  release earlier in the same run.
• The tag is not in the github.ref of a workflow_call run the way it is for
  a tag push, so mix tinfoil.publish likely needs the tag passed explicitly.
  A tag input on the reusable workflow, defaulting to
  github.event.release.tag_name when absent, would cover both.
• workflow_dispatch alongside it makes a failed release re-runnable without
  retagging, which the tag-push trigger cannot offer.

Docs should probably also carry a short warning about the GITHUB_TOKEN rule
for anyone staying on :tag_push or :release_published, since the failure is
completely silent.