HydraIssues

Add a second build TYPE to the Linux pipeline: a "release" build that produces a non-container artifact (a binary, an AppImage, a tarball) and publishes it to the release server, alongside the existing "scale" build (Dockerfile -> OCI image -> deployed scale).

WHY
The builder underneath the pipeline (hydrapipelinerunnerlinux launching an ephemeral rootless-buildkit scale on a native-arch hydraskin node) is already a GENERAL Linux build environment. Only the two ends are container-specific: the output is hardwired to an OCI image, and delivery is hardwired to a scale deploy. Generalising those two ends turns the Linux pipeline into the fleet's own native Linux build machine - the exact analog of Darwin builds running on cederikmini via hydrapipelinerunnerapple, instead of GitHub runners. Concretely it lets non-container Linux artifacts build on native arm64 fleet hardware: e.g. the hydraheadflatscreen agent (hydrahead-linux-amd64/arm64) and the HydraExperienceNet AppImage, which today build on GitHub Actions.

SCOPE TODAY (for contrast): the pipeline is OCI-container-scales-only, documented in the hydralinuxpipeline README/runbook and hydramancer /deploy. This issue is the extension, not a bug.

DESIGN

1. Build TYPE per project, declared in .hydrabuild.yaml (or the watch config): type: scale (default, current behaviour) or type: release.
2. Runner OUTPUT mode. Today dispatch hardcodes buildctl --output type=image,name=...,push=true. For a release build, use --output type=local,dest=<outdir> (or type=tar) and collect the produced artifact(s). The Dockerfile's final stage stages the artifact (binary/AppImage) at a known path; buildctl extracts it. Native arch, no QEMU, same as now.
3. DELIVERY mode. A scale build pushes the image + does hydraskin launch/update. A release build instead PUBLISHES the artifact to releases.experiencenet.com via the publish API (HYDRARELEASE_PUBLISH_TOKEN), under the project/channel/version path the updater already reads - no scale, no node deploy. Keep the vertical separation the owner set: scales never go to HydraRelease/ExperienceLibrary; release artifacts DO belong on the release server (that is their correct home).
4. Pipeline job model. The job's terminal is "published" (artifact on the release server) instead of "live" (scale deployed). No deploy intent (domain/port/disk/target_node) for a release build; instead a release project name + channel + artifact list.
5. Watcher. The build-notify carries the build type; a release project sends the release fields (project/channel), not the scale deploy intent. A v* tag triggers a release publish; a branch push could build-only (validate) with no publish.
6. Builder image deps. A Go binary needs nothing extra. An AppImage (Qt) needs the GUI build deps in the ephemeral builder: Qt, linuxdeploy + the qt plugin, X11/EGL libs. Either a richer hydra-builder image variant, or the project's Dockerfile installs them. Carry the known AppImage gotchas from the omarchy work (#493/#500): use linuxdeploy + qt plugin (NOT linuxdeployqt, which dies silently upstream), and exclude the libva family from the AppImage so the host VAAPI driver loads.

ACCEPTANCE

• A repo with type: release and a Dockerfile that stages a linux-arm64 binary: a v* tag builds it natively on a fleet arm64 builder and the binary appears on releases.experiencenet.com under its project/channel/version, consumable by the hydrarelease updater. No scale is created.
• The existing type: scale path is unchanged.
• Docs: the OCI-only scope note in the README/runbook/hydramancer is updated to describe both build types.

RELATED: #508 (Linux pipeline), #520 (deployment hardening follow-ups). Fleet analog: hydrapipelinerunnerapple + cederikmini for Darwin.