[folbricht]

Both architectures build cleanly — verified during #387 — and are a natural fit for the embedded/appliance update case, which is one of desync's core uses. Neither was in the release matrix, so those users had to build from source.

Adds arm and riscv64, restricted to Linux. Of the other platforms, go tool dist list says only freebsd/arm is a combination Go supports at all (darwin and windows support neither), and FreeBSD is already "builds, untested at runtime", so a second architecture there would be an artifact nobody exercises. The ignore rule covers that deliberate omission; goreleaser skips the genuinely invalid combinations by itself.

Both ARM variants are built. v6 runs anywhere 32-bit ARM does, v7 is faster on hardware that supports it, and desync's chunking is CPU-bound enough for that to be worth an extra artifact.

Verified with a full goreleaser build --snapshot across the whole matrix, which now produces:

linux:   amd64  arm_6  arm_7  arm64  riscv64
darwin:  amd64  arm64
windows: amd64  arm64
freebsd: amd64  arm64

No invalid combination is attempted and freebsd/arm is correctly absent, so a real tag push won't fail on the matrix. goreleaser check passes.

The new binaries are the right thing (ELF 32-bit ARM EABI5 for both ARM variants, UCB RISC-V double-float for riscv64) and the v6/v7 outputs genuinely differ. Beyond that they were run under qemu user emulation, which is more than a file(1) check:

• all three report their version correctly, so the ldflags stamping works on these targets too
• make under arm/v7 into a local store, then extract of that index under riscv64, compared byte-for-byte against the original
• verify of the resulting store under arm/v6

So the artifacts run, and interoperate across architectures.