Publish a real apt-cosign-verified apt repo (dists/stable/...), not just per-file releases

wr-salt-new is switching from direct `.deb` downloads (`pkg.installed(sources=...)`, sha256-pinned) to installing via `non7top/apt-cosign`'s `sigstore+https://` apt acquire method, so this repo needs to actually serve a real apt tree, not just per-file GitHub Releases.

Per apt-cosign's README ("Hosting a repo on raw.githubusercontent.com"):

1. Build a real apt tree in this repo, e.g. `dists/stable/{InRelease,Packages,...}` - since this is a tiny, single-package repo, a lightweight hand-generated `Packages`/`InRelease` (or a small script) is probably enough; full `reprepro`/`aptly` is likely overkill but worth a quick look.
2. In CI (after the existing per-OS `.deb` build), commit the built `.deb`(s) into the tree and regenerate `Packages`/`InRelease`.
3. Sign `InRelease` with `apt-cosign-sign` (keyless, GitHub Actions OIDC - same `id-token: write` permission and identity this repo's workflow already uses for cosign signing), committing the resulting `InRelease.sigstore` alongside it.
4. Consumers point at `sigstore+https://raw.githubusercontent.com/non7top/nginx-modules/refs/heads/main/dists/stable\` and configure `Enforce::Repo` (Owner=non7top, Name=nginx-modules, Pipeline=<this build workflow's filename>) in their apt-cosign policy.

Verify end-to-end (install via real `apt-get install`, not just `dpkg -i`) before wiring wr-salt-new's `ispconfig3/vts.sls` to it.

Start with the existing per-OS .deb build workflow and the apt-cosign README section on hosting a repository on raw.githubusercontent.com. Trace how the workflow currently builds and signs packages, then verify the dists/stable tree end to end with apt-get install before changing wr-salt-new/ispconfig3/vts.sls.