ci(release): pre-built binaries for linux, macos and windows

[quartzjer]

What

Adds a tag-triggered release.yml, so pushing a v* tag builds every variant and attaches the bundles to that release.

It's the same workflow ced.cpp, voice-detect.cpp and face-detect.cpp already use, adapted to this project. face-detect.cpp is the closest match, since it's the other one that applies in-tree ggml patches and so needs the explicit patch step on windows.

Per (platform, backend) pair it builds twice and produces two bundles:

• rfdetr-<ver>-bin-<platform>-<backend>-<arch> — a self-contained rfdetr-cli with LICENSE and README.md. BUILD_SHARED_LIBS=OFF folds the ggml backends into the binary, and GGML_NATIVE=OFF keeps it portable across CPUs. That last one is deliberately unlike ci.yml, which sets GGML_NATIVE=ON because it only has to run on its own runner.
• rfdetr-<ver>-lib-<platform>-<backend>-<arch> — the shared library (rfdetr.dll on windows) plus rfdetr_capi.h, for the dlopen/FFI consumers. The windows tokens are win, not windows: rfdetr-v0.1.0-solpbc.5-bin-win-cuda-x64.zip.

Variants: linux x64 cpu/vulkan/cuda and arm64 cpu, macos arm64 metal and x64 cpu, windows x64 cpu/vulkan/cuda. The linux CUDA bundles carry libcudart/libcublas/libcublasLt next to the binary with an $ORIGIN rpath; the windows CUDA bundles expect a CUDA install, matching the sibling engines. Every job that can run its own binary does a usage-banner smoke test before packaging. macos x64 is cross-compiled on the arm64 runner, so it's build-only. A v* tag creates a draft release if one doesn't exist yet, so tagging before or after creating the release both work.

Why

There are no releases today, so anyone integrating rf-detr.cpp either builds from source or carries their own binaries. We're in the second group, running a self-built rfdetr-cli from a fork since May. Our C-API consumers want a bundle, not a toolchain.

Nothing here changes how LocalAI consumes this repo; that stays a source build at a commit pin.

Notes

• Depends on Build on Windows with MSVC #4, "Build on Windows with MSVC". The tree doesn't build under MSVC today, so the three windows jobs can't pass without those fixes. Nothing here runs on a PR or a branch push, only on a v* tag or a manual workflow_dispatch, so merging this first turns nothing red immediately. It breaks the first tagged release instead: the release job is gated both on github.ref_type == 'tag' and on every build job, so a red windows job means the tag ships no assets at all.
• Run end-to-end on a fork, on a tree with Build on Windows with MSVC #4 applied: https://github.com/solpbc/rf-detr.cpp/actions/runs/32324442080. All nine build jobs green, the release job ran, and the release carries 18 assets, a bin and a lib bundle per job: https://github.com/solpbc/rf-detr.cpp/releases/tag/v0.1.0-solpbc.5
• Three of the bundles were run on real hardware rather than just built: linux x64, linux arm64, and macos arm64 metal each produce 5/5 matches against tests/fixtures/ci/expected_nano-f16.json via tests/ci/compare_detections.py. On the macos run the log shows [INFO] GPU backend: Metal with no fallback warning, so Metal initialized rather than falling back to CPU-only.
• The cost, before you decide whether the CUDA jobs earn their keep: build-windows (cuda) took 191 minutes and build-linux (cuda) 140 minutes, so the two of them are about 331 of the run's ~350 job-minutes. Both compile CUDA twice, once for the binary and once for the shared lib. The longest of the rest is build-windows (vulkan) at 8m35s. The linux CUDA bundles also land at 537 MB each, bin and lib alike.
• I matched face-detect.cpp deliberately rather than tuning it. Two places differ because this project differs: the binary is at build/bin/rfdetr-cli and the library at build-shared/lib/, or build-shared/bin/ for the dll on windows (this repo sets CMAKE_RUNTIME_OUTPUT_DIRECTORY / CMAKE_LIBRARY_OUTPUT_DIRECTORY, face-detect doesn't), and the shared-lib flag is RFDETR_SHARED.
• Happy to trim the matrix. Dropping the CUDA or windows jobs is a small edit, and I'd rather ship the shape you want to maintain.

[localai-org-maint-bot]

@mudler The workflow is technically coherent and the contributor validated all nine matrix jobs plus the 18 release assets, but I recommend merging #4 first because every Windows lane depends on it. The maintenance decision is cost: the two CUDA lanes account for roughly 331 of ~350 job-minutes and produce 537 MB Linux bundles. If that release cost is acceptable, this is ready after #4; otherwise trim CUDA before the first tag.