Serve the admin from the binary and publish signed release files #457

Part 1. Serve the admin app from inside the binary

Current state: The server reads the admin app and the public block stylesheets from a folder named by GOPHENBERG_WEB_DIR. Without that setting, /admin/ and the stylesheets answer 404. The container image copies the built admin to /web and sets the setting. A downloaded binary on its own cannot show the admin.

Proposal:

• A release build carries the built admin inside the binary, behind an embedweb build tag.
• GOPHENBERG_WEB_DIR stays as an override for development. A named folder must hold index.html, or serve and check refuse to start with a clear sentence.
• A build without the admin serves a short page that says how to get one.
• make build-release builds the admin, copies it in, checks that the real admin is inside, and builds the binary.
• The admin's hashed files may be kept for GOPHENBERG_CACHE_ADMIN_ASSET_MAX_AGE, default one year, and the admin page is checked on every load.
• The image no longer holds /web. The end-to-end tests run on the built-in admin.

Trigger: Release archives and a one-command installer need one file that serves everything.

Part 2. Sign and verify release files

Current state: Releases publish one container image and no files. Nothing is signed, and there is no tool to make keys.

Proposal:

• A signing package that signs and checks files as FAIR packages do today: Ed25519 over the SHA-384 digest, written as base64url without padding, with checksums written as sha256: and lowercase hex.
• A releasetool command with keygen, sign and verify.
• keygen makes Ed25519 release keys and P-256 root keys, seals root keys with a passphrase in a form OpenSSL opens, and prints each public key as a Multikey.
• Tests check live FAIR signatures from their digest, signature and key only, a test vector that OpenSSL signs to the same bytes, and a changed byte.

Trigger: Signed archives, and later signed update checks, need keys and a signer first.

Part 3. Publish signed archives with every release

Current state: A release tag pushes one linux/amd64 image. The GitHub Release holds notes only. The binary is built without -trimpath and carries no build stamp or commit.

Proposal:

• Each tag builds archives for Linux amd64 and arm64 and macOS arm64. Each holds the binary, release.json and the license notices.
• A protected job the maintainer approves signs every file and writes SHA256SUMS and a release record. The record lists each archive with its id, content type, platform, checksum and signature.
• GitHub provenance covers every file. A multi-architecture image with an SBOM is built from the same signed binaries.
• Pre-release tags and older branches never move latest, and pre-release tags deploy no docs.
• Every pull request checks an archive with OpenSSL alone, and checks that the image and the archive hold the same binary on both Linux platforms.

Trigger: The installer and the updater must check what they download, with OpenSSL alone on a fresh server.