Publish the Docker image automatically on release

[7sharp9]

Follow-up to #234, item 3 ("Releasing a docker image on publish"). Deferred out of
#234's scope by ADR-0021
(decision 4), which kept #234 focused on versioning/changelog automation.

Problem

dotnet run DockerBuild builds halcwb/genpres locally and labels it with the
<Version> from the root Directory.Build.props, but nothing publishes it. Every
release image is built and pushed by hand, so there is no guarantee that a published
tag corresponds to the commit that produced the matching CHANGELOG.md entry.

What's already in place

• Dockerfile takes an APP_VERSION build arg and writes it to
  org.opencontainers.image.version.
• DockerBuild / DockerRun FAKE targets (Build.fs), with DOCKER_IMAGE and
  DOCKER_PLATFORM overrides.
• EasyBuild.ShipIt now owns version derivation and opens the release PR
  (.github/workflows/release.yml), so there is a well-defined "a release happened"
  event to hang publishing off.

Scope to decide

• Trigger: on the release PR merging, on a git tag, or on a GitHub Release being
  published. ShipIt's behaviour on merge determines which of these actually fires.
• Registry: Docker Hub (halcwb/genpres, matching the current default) vs GHCR.
  Needs a credentials/secrets decision either way.
• Tags to push: :<version>, :latest, and whether pre-release versions
  (0.1.2-alpha.N) should move :latest at all — currently every release is a
  pre-release, so :latest semantics need settling before this is switched on.
• Multi-arch (linux/amd64 + linux/arm64) via buildx, or single-arch to start.
• Whether the published image is smoke-tested before the tag is considered good.

Constraints

• GENPRES_URL_ID and GENPRES_PASSWORD must not be baked into the image
  (see DEVELOPMENT.md § Environment Configuration) — no --build-arg for either.
  A publish workflow must not introduce them as build args by accident.
• Publishing must not block the test/format matrix in build.yml, for the same
  reason release.yml is a separate workflow.

Likely wants an ADR-0021 amendment rather than a new ADR.

[7sharp9]

Recording an answer to the "Trigger" bullet under Scope to decide, so nobody designs an on: release workflow that never fires.

Of the three candidate triggers listed — release PR merge, git tag, GitHub Release published — only release-PR-merge is available today. upstream/master has zero
git tags and zero GitHub Releases across all three shipped versions (0.1.2-alpha.2, .3, .4). EasyBuild.ShipIt in --mode pull-request bumps
Directory.Build.props, writes the CHANGELOG.md section, opens the release PR, and stops. Verified against the installed tool (3.0.1): its assembly contains no tag,
no refs/, and no releases API endpoint, so it cannot create either artifact in any mode. The github subcommand is provider-forcing, not a publish-a-Release command,
and --mode push only changes how the changelog commit reaches master.

Two further points worth having on record before this is implemented:

1. Do not copy ShipIt's documented release-job trigger. Its README suggests if: startsWith(github.event.head_commit.message, 'chore: release '). Every
   release PR here has merged as a true merge commit (chore: release GenPRES@0.1.2-alpha.2 #455 944c8d34, chore: release GenPRES@0.1.2-alpha.3 #458 5ea9b320, chore: release GenPRES@0.1.2-alpha.4 #464 9d1d017e, two parents each), so the push event's
   head_commit.message is Merge pull request #NNN from informedica/release/master, never chore: release .... That condition is 0 for 3. A merge-method-independent
   condition on the PR itself works instead:

   on:
     pull_request:
       types: [closed]
   
   jobs:
     publish:
       if: >-
         github.event.pull_request.merged == true &&
         github.event.pull_request.head.ref == 'release/master'

   ShipIt also consistently labels the PR easybuild-release:pending, which is a second usable signal.

2. If tags/Releases do get added later, GITHUB_TOKEN blocks the chain. Actions taken with the default GITHUB_TOKEN do not trigger further workflow runs, so a
   tag created that way would not fire an on: push: tags: or on: release Docker publish. Either publishing stays a downstream job of the same workflow, or the tag
   is created with a PAT / App token.

The tag-and-Release gap is being tracked separately as a follow-up to #234 item 2; if that lands first, this issue's trigger can move to the tag it creates. Until then,
release-PR-merge is the only event that does occur.