Restore compatible Neko release image builds

[sjmiller609]

Summary

The v3.0.8-v1.6.1 release cannot build: Bullseye security package indexes advertise files that now return 404 from the normal security mirror. The existing Go builder also links the server against a newer libc than the Bullseye runtime provides.

• Use the signed Debian archive security repository for the Bullseye runtime, Xorg builder, and server builder. No APT signature or expiry checks are disabled.
• Build the server and plugins on Bullseye, copying the unchanged Go 1.25.0 toolchain from its official image. This preserves the runtime ABI instead of upgrading the runtime OS.
• Set GOTOOLCHAIN=local to preserve the official Go image's pin and reject dependencies requiring a newer toolchain.
• Keep the crypto/network dependency upgrades from PR Update Go crypto and network dependencies #25.

Verification

• Reproduced the package-download 404s independently; the archive mirror installs the same packages successfully.
• Reproduced the old builder binary failing to load in the published Bullseye base because GLIBC_2.32 and GLIBC_2.34 were unavailable.
• Generated the full release Dockerfile using the release client artifact and built the complete amd64 base image successfully.
• Ran /usr/bin/neko --version inside the new base image successfully.
• Ran go test -race ./..., go vet ./..., and go mod verify in the new server builder; all passed.
• Verified the packaged binary embeds x/crypto v0.54.0 and x/net v0.57.0.
• Verified a synthetic module requiring Go 1.26.0 fails with GOTOOLCHAIN=local instead of downloading another toolchain.
• amd64/arm64 server builds and server tests passed in CI for the toolchain-pin update.
• Multi-architecture release builds and browser live-view e2e were not run locally.

Release

After merging, publish a new tag v3.0.8-v1.6.2; do not move the existing failed v3.0.8-v1.6.1 tag. Update the dependent browser image pins after the new base is published.

Bullseye is retained for compatibility in this bounded release fix. Migrating the runtime to a supported Debian release remains separate work.

---

Note

Medium Risk
Changes release build infrastructure and package mirrors for EOL Bullseye; incorrect mirror or toolchain wiring could break CI/releases, but scope is limited to Docker build paths.

Overview
Fixes broken v3.0.8 release image builds by pointing Bullseye APT security sources at archive.debian.org/debian-security in the runtime, server builder, and xorg-deps Dockerfiles so apt-get no longer hits 404s on the live security mirror.

The server image no longer uses golang:1.25.0 as the build stage base. It builds on debian:bullseye-slim and copies the Go 1.25.0 toolchain from a separate stage, with added compile packages (build-essential, git, etc.), so binaries link against Bullseye’s glibc and run in the published runtime without GLIBC_2.32/2.34 errors.

^{Reviewed by Cursor Bugbot for commit 1745c26. Bugbot is set up for automated code reviews on this repo. Configure here.}

[sjmiller609]

Additional runtime verification: started the complete rebuilt amd64 base image with its normal supervisord entrypoint. Neko, Xorg, and PulseAudio were all RUNNING; /health succeeded and the web client returned HTTP 200. Logs confirm video-pipeline syntax validation and startup of the filetransfer, chat, scaletozero, and telemetry plugins. This verifies full base-image startup, not browser WebRTC playback or a published multi-architecture release.

[rgarcia]

reviewed — lgtm, approving. a few non-blocking things:

Suggestions

• server/Dockerfile:5-7 — the copied toolchain doesn't carry over the golang image's ENV GOTOOLCHAIN=local (verified: docker run golang:1.25.0 env shows it). without it go falls back to auto, so if a future dep bump requires a go version newer than 1.25.0, the go get in ./build will silently download a newer toolchain instead of failing. consider adding ENV GOTOOLCHAIN=local next to GOPATH/PATH so the builder actually stays pinned to 1.25.0

Questions

• runtime/Dockerfile.intel:17 — the intel flavor writes its own sources.list with deb.debian.org/debian-security, so it would hit the same 404s if ghcr_intel.yml.bak is ever re-enabled. fine to leave since it's not released, just flagging
• only bullseye-security moves to the archive here; main is still served from deb.debian.org and will break the same way once debian archives the rest of bullseye. is the move off bullseye tracked somewhere?
• the tag build in ghcr.yml does amd64 + arm64 + arm/v7 under qemu, and the PR says only amd64 was built locally. worth watching the v3.0.8-v1.6.2 run before bumping the browser image pins

[sjmiller609]

Added GOTOOLCHAIN=local to preserve the original official Go image behavior. Rebuilt the server builder; race-enabled tests, vet, and module verification pass. A synthetic module requiring Go 1.26.0 now fails explicitly while running Go 1.25.0 with GOTOOLCHAIN=local instead of downloading a newer toolchain. The disabled Intel flavor is unchanged. Browser-image pins will only be updated after the tagged multi-architecture base release succeeds.