Tagged releases would unlock downstream packaging

Thank you for **ds4** @antirez. A small native engine that streams experts from SSD is the piece that makes near-frontier models real on hardware people actually own, and I would like to build on it.

I maintain [SibillaOS](https://github.com/engineering87/sibillaos), an Ubuntu based distribution that turns a machine into a local LLM appliance. Every component we ship is pinned to an exact upstream version and verified against sha256 digests in a GPG signed catalog. We already repackage llmfit into a signed deb from its release assets, and we want to do the same with ds4 as our engine for the unified memory tier (Strix Halo, DGX Spark, 96GB+ machines), where SSD streaming shines.

The one thing we cannot do today is pin: the repo has no tags and no releases yet, so there is no stable reference to verify and repackage.

Any of these would unlock us, in order of usefulness:

1. Version tags on commits you consider good, even without binaries. We build from the tag and carry the toolchain burden
2. Releases with source tarballs and a SHA256SUMS file
3. Prebuilt Linux binaries as release assets. Useful, but we understand it is real maintenance surface

In exchange we are happy to maintain the Debian packaging downstream, report hardware validation results from our users' machines, and document ds4 as a first class engine in a distribution with a verified supply chain.

No urgency at all. `QA_BEFORE_RELEASES.md` shows you take releases seriously, and that is precisely why we would rather wait for your tags than pin an arbitrary commit.