Add reusable publish workflow and migrate gem repos to caller pattern

[jonrandahl]

Each gem repository currently maintains its own copy of publish.yml. This means any change to the publish logic requires updating every repo individually which is a brittle and error-prone pattern. This issue tracks two related pieces of work: introducing a shared reusable workflow in epimorphics/github-workflows, and updating each gem repo to call it.

Objective

Add .github/workflows/publish-gem.yml to this repository as a reusable workflow_call workflow, then replace the contents of .github/workflows/publish.yml in each gem repository with a lightweight caller that delegates to it. This gives us a single place to maintain publish logic and ensures all gems stay in sync going forward.

Implementation

1. Introduce the .github/workflows/publish-gem.yml reusable workflow in a linked PR.
2. Each gem repo's .github/workflows/publish.yml should then be replaced with the following caller:

name: Release and Publish Gem

on:
  workflow_dispatch:

jobs:
  publish:
    uses: epimorphics/github-workflows/.github/workflows/publish-gem.yml@v1
    if: github.ref == 'refs/heads/main'
    secrets:
      github_token: ${{ secrets.GITHUB_TOKEN }}

Definition of done

• The reusable workflow is merged and tagged @v1 in epimorphics/github-workflows
• All gem repos have their publish.yml replaced with the caller above - no other workflow logic is retained in the file
• All gem repos have their tags makefile target updated to include name, owner, and version outputs
• A manual workflow_dispatch run on main in at least one gem confirms the job triggers and completes successfully via the reusable workflow
• No gem-specific publish logic remains duplicated outside of github-workflows

---

Note

• Branch guard on the job, not the trigger

  The if: github.ref == 'refs/heads/main' condition is intentionally placed at the job level rather than as a trigger filter. A workflow_dispatch can be fired from any branch via the GitHub UI, so without this guard an operator could accidentally trigger a publish from a feature branch. Keeping it on the job ensures the release only proceeds when run against main, regardless of how the workflow was invoked.

• Gems with custom publish logic

  If a gem's current publish.yml contains any logic beyond a basic publish step, raise a separate issue before migrating it. Those cases need review to determine whether the custom behaviour should be absorbed into the shared workflow or handled another way.

• Future changes

  Any updates to publish behaviour should be made only in epimorphics/github-workflows and released under a new version tag. Do not patch individual gem callers directly.

[jonrandahl]

Linked PR for reusable workflow: #7

[jonrandahl]

First gem update to use this when ready: epimorphics/json-rails-logger#75