Ship a musl/Alpine package so Alpine is supported, not just refused

## Why

The glow-up platform matrix now runs the package on Alpine 3.21–3.24 and proves it **cannot** run there:

```
ok Alpine 3.24 musl 1.2.6 cannot run, as declared
ok Alpine 3.23 musl 1.2.5 cannot run, as declared
ok Alpine 3.22 musl 1.2.5 cannot run, as declared
ok Alpine 3.21 musl 1.2.5 cannot run, as declared
```

Proving the refusal is honest, but the goal is to serve those users. musl is not an older glibc, so lowering the glibc floor (#181) does nothing here — it needs a separately linked package.

## Scope

This is real work, not a packaging flag:

1. **Link the host cohort against musl.** `x86_64-unknown-linux-musl` and `aarch64-unknown-linux-musl` are already in the toolchain (the guest agent cohort uses them), so the pure-Rust binaries — `capsem`, `capsem-service`, `capsem-process`, `capsem-tui`, `capsem-mcp*`, `capsem-gateway`, `capsem-admin`, `capsem-mock-server`, `capsem-bench-rs` — are the tractable part.
2. **Decide what happens to `capsem-app`.** The Tauri shell links webkit2gtk/GTK. Alpine carries those, but Tauri on musl is the unproven piece. A CLI/service-only Alpine package may be the right first cut, with the desktop shell out of scope.
3. **Service registration.** The installer emits systemd units on Linux; Alpine is OpenRC. `generate_unit()` gains a sibling, and the install/uninstall/update paths need to select between them.
4. **`.apk` packaging and signing**, alongside the existing `.deb` and macOS `.pkg` rails.
5. **`install.sh`** currently hard-fails without `apt`; it needs an `apk` branch.
6. **Manifest and release lanes** carry a third artifact family.

## Done when

The four Alpine rows in `[platforms.linux.distributions]` flip from `cannot run` to `runs`, driven by the musl package rather than by editing the expectation. The proof derives the expectation from each image's real libc, so it follows this change without being updated.

## Related

- #174 — the deb declared no libc floor at all (fixed)
- #181 — lower the glibc floor to cover Ubuntu 22.04 / Debian 12

Start by inspecting the existing musl guest-agent toolchain targets and the current .deb packaging and release lanes. Then trace generate_unit(), the install/uninstall/update paths, and install.sh to determine service selection and the apk branch; done means the four Alpine platform rows report runs using the musl package, with the manifest and release artifacts included.

Written by the indexing model from the issue text.