ci(flatpak): integrate aetherpak registry publishing

[abn]

👋 With the recent changes in Flathub's acceptance policy regarding AI assistance in application code, I reckon toolhive-studio might be unlikely to be accepted there.

To address this, I'm proposing self-hosting a dedicated flatpak repository using AetherPak (GH Pages + GHCR OCI). It lets Linux users add the remote once and then receive updates natively through their software manager (Gnome Software, Discover, etc.). You can see an example of a multi-app repository hosted this way at https://abn.github.io/flatpakrepo/.

I've reused the existing flatpak build outputs in the release workflow to keep this PR additive:

• Tagged stable releases publish to the stable flatpak channel.
• Tagged pre-releases publish to the beta flatpak channel.
• Pull requests only run a build verification check (no registry uploads).

The repository files are isolated under the /flatpak subpath to avoid clashing with other GitHub Pages deployments, and the landing page template is customized to match the Stacklok brand.

In the future, once we have a static manifest (#454), we can drop the custom flatpak setups on the runners and simplify the workflow to use the reusable AetherPak workflow:

jobs:
  publish-flatpak:
    uses: aetherpak/actions/.github/workflows/publish.yml@v3
    with:
      manifest-path: flatpak/com.stacklok.ToolHive.json
      pages-url: https://stacklok.github.io/toolhive-studio
      site-subpath: flatpak
      remote-name: toolhive
      index-template: .github/workflows/templates/stacklok.html
    secrets: inherit

To set this up, you'll need:

1. GitHub Pages configured to deploy via Actions.
2. The GHCR package visibility set to Public (so clients can pull OCI layers anonymously).
3. (Optional but recommended) AETHERPAK_GPG_PRIVATE_KEY and AETHERPAK_GPG_PRIVATE_KEY_PASSPHRASE repository secrets. Without these, the workflow will publish unsigned packages (current posture).

Let me know what you think! And here is a screenshot of what the index will look like.

cc: @kantord (since you are working on #454)

PS:

• Opening this as a draft for now as I am not sure what the appetite for this change in the project.
• A large chunk of this change is the index template (~300 lines). If the customisation is not required we can drop it too.

[kantord]

Hi @abn this is very interesting and cool! 👀 I had no idea you could do this

[abn]

@kantord you and me both, well till around last week 😅. It's not perfect but a significant improvement over the current options.

Let me know if you'd like to try pushing this forward, happy to assist the best I can.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds Flatpak publishing and a branded Flatpak repository landing page, integrated into the release pipeline and Pages mirroring.

Changes:

• Introduces a Stacklok-branded HTML template for the generated Flatpak repo site.
• Uploads Flatpak bundles as CI artifacts and publishes them to GHCR on release.
• Integrates site artifact download into the Pages mirroring workflow.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 8 comments.

File	Description
.github/workflows/templates/stacklok.html	Adds a dynamic, branded Flatpak repository landing page template consumed by the publishing workflow.
.github/workflows/pr-build-test.yml	Adds permissions and uploads Flatpak bundle artifacts for Linux runs.
.github/workflows/on-release.yml	Adds Flatpak publish job (GHCR + site index) and wires it into the release pipeline.
.github/workflows/mirror-to-gh-pages.yml	Downloads the generated site artifact before deploying GitHub Pages (stable only).