D121 — Release as Linux tarball and KiCad plugin package

Decision

A release is two files built and tested by CI: a Linux x86_64 tarball (the three binaries, the built viewer, an example board, the agent skills) and the KiCad plugin package with the router, the placer and the viewer inside. They come from the dist preset (CPU only, libstdc++, libgcc, SQLite and zstd linked statically; RelWithDebInfo stripped at install so the code is the tested code), need glibc 2.38 and nothing else, and the binaries find the viewer at ../share/tracemaker/viewer or TM_VIEW_DIR. The Release files workflow builds them in the CI container, installs them in a clean Ubuntu 24.04 container with no compiler or Python, routes the example, and on a v* tag attaches them to the release as a draft

Alternatives

Building on an older glibc to run on Ubuntu 22.04 and Debian 12 (needs GCC 15 on an old distribution; recorded as the way to widen the floor); a .deb/AppImage/Flatpak/Docker image; a Python module in the plugin package (it must match KiCad's Python and the plugin falls back to the binary); macOS arm64 (the presets exist, nothing was built or run); a CUDA build (GPU memory is shared and the CPU path is the reference); publishing without a draft

Reason

Release 0.9.0 has only a video, and GCC 15 is a high bar for hobbyists. A static CPU binary and a zip are the least that gets a person to a routed board in five minutes; checked on Ubuntu 24.04, Debian 13 and current Fedora in 5 s, and the unpacked plugin in a live KiCad 10.0.6 (bench/records/m17). The workflow's package and install jobs passed on GitHub in the pull request (PR #44); its tag-triggered publish step (draft release) has not run yet