Add gated Docker Hub stable releases

[magiccodingman]

What changed

• extracts the existing Compose validation and native AMD64/ARM64 appliance smoke tests into a reusable workflow
• keeps master publishing the rolling GHCR master and SHA images after the reusable appliance gate passes
• adds a separate stable-branch release orchestrator that waits for:
  • the complete appliance CI workflow
  • legacy Kubo repository migration tests on AMD64 and ARM64
  • TLS lifecycle tests
• publishes one Docker Hub multi-platform image for linux/amd64 and linux/arm64
• synchronizes the root README.md to the Docker Hub repository only after image publication and remote manifest verification succeed

Stable tags

The Docker Hub release publishes these tags for the same image:

• stable
• latest
• the current major/minor series, initially 0.1
• the allocated full version, initially 0.1.0
• sha-<commit>

VERSION contains only the intentional major/minor series. Each newly promoted stable commit automatically receives the next patch version. Full version tags are never intentionally moved; stable, latest, and the series tag move forward.

Version allocation is rerun-safe: if a failed release run already tagged the stable commit, the next run reuses that tag instead of incrementing again. Release concurrency is serialized and is not cancelled by a newer stable push.

Release sequence

1. A commit reaches stable.
2. Appliance, migration, and TLS gates run in parallel.
3. After all gates pass, the workflow assigns or reuses the semantic version Git tag.
4. Docker Hub publishes the AMD64/ARM64 manifest and all release tags.
5. The workflow inspects the remote manifest and verifies both architectures.
6. Docker Hub's overview is updated from README.md as the final job.

Git tags created with GITHUB_TOKEN intentionally do not need to trigger another workflow because tagging and publishing occur in this same orchestrated run.

Image defaults and documentation

• compose.yaml and .env.example now default to magiccodingman/truthgate-ipfs:stable
• the rolling GHCR image remains available for development from master
• README and Docker documentation now distinguish pulling stable releases from building locally
• deployments can pin TRUTHGATE_IMAGE to an immutable full version

Regression protection

The reusable runtime smoke test now downloads /_framework/blazor.web.js after initial boot and again after container replacement, requiring a nontrivial payload. This covers the production-publish failure that previously left the portal rendered but noninteractive.

Required repository configuration

The workflow uses the existing repository secrets:

• DOCKERHUB_USERNAME
• DOCKERHUB_TOKEN

The token must be allowed to push and update the Docker Hub repository description. The intended repository is <DOCKERHUB_USERNAME>/truthgate-ipfs.

First release

After this PR is merged to master, promoting that commit to a stable branch will create the first stable version as v0.1.0 unless a matching v0.1.x tag already exists.