fix(ci): keep the server publish workflows off site releases

[BryanFRD]

The first site release, site@2026.8.18, fired every release-triggered workflow in the repository. Docker routed correctly (site image built, server image skipped — #143 did its job), and Chart skipped itself because it already guards on a v tag. Publish and Binaries did neither: both ran against server artefacts under a site tag and failed.

They failed rather than published the wrong thing, which is luck rather than design — publish.yml checks out github.event.release.tag_name and goes straight at crates.io and npm, and those are publications that cannot be taken back.

Both now carry the same guard chart.yml already had:

if: startsWith(github.event.release.tag_name, 'v') || github.event_name == 'workflow_dispatch'

binaries.yml only needs it on build: verify and npm declare needs: build, so a skipped build skips them too. publish.yml has a single job.

This is the same class of bug as #143 and I should have swept for it there instead of fixing only the workflow I happened to be looking at. Every on: release workflow in a repository that now releases two things under two tag shapes needed checking, and I checked one.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[ferrfleet]

Guard mirrors the existing chart.yml pattern exactly. Verified binaries.yml: verify and npm both declare needs: build, so skipping build on a non-v tag correctly skips them too — no separate guard needed there. publish.yml has a single job, guarded directly. Looks correct.

[github-actions]

SonarQube — aucune nouvelle issue

_{Comparaison entre le projet bac à sable de cette PR et la branche par défaut : SonarQube Community n'analyse pas les PR, ce delta est calculé côté CI. Détail}