fix(ci): unbreak the image build, and prove the Dockerfile before a release needs it

[BryanFRD]

No image has been published since 0.20.0. Five releases — 0.21.0, 0.22.0, 0.23.0, 0.23.1, 0.24.0 — are tagged, have charts, and have no container behind them. GHCR stops at 0.20.0.

The cause is one line. The sccache work in 0.21.0 added export ACTIONS_CACHE_URL="$(cat ...)", and hadolint runs with --failure-threshold warning, so SC2155 ("declare and assign separately to avoid masking return values") fails the job. Assigning first and exporting after is the fix.

The reason nobody noticed is the more interesting half. The image is built on release only, so the Dockerfile is exercised for the first time after a version exists. Every release since has been publishing a chart whose appVersion names an image that was never pushed — which is exactly the trap the homelab fell into an hour ago: Homelab#94 moved the release to chart 0.23.1, the pod could not pull ghcr.io/ferrlabs/lfsx:0.23.1, and the service was down for about seventeen minutes until Flux gave up and rolled back.

So this PR also makes a change to Dockerfile prove itself before merging: a pull_request trigger, path-filtered to the file and this workflow, running the same reusable with push: false and amd64 only. Lint and build, no registry, no signing, no Trivy — those stay on the release path. It is one build on the rare PR that touches the file, against five silent releases.

No smoke test on that job on purpose: the release path keeps it, and duplicating the script here would be one more thing to drift.

After this merges, the images for the missing versions still have to be published by dispatching this workflow per version.

[Copilot]

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

[ferrfleet]

Both changes check out.

• Dockerfile: the SC2155 fix (assign then export VAR1 VAR2) is correct and behaviorally identical to before.
• docker.yml: the new pull_request-triggered verify job is properly scoped — it's the only job that runs on pull_request events (if: github.event_name == 'pull_request'), while meta/build stay gated to release/workflow_dispatch via their own condition, so nothing tries to push or sign on a PR. push: false, amd64-only, path-filtered to Dockerfile + the workflow file, matching the PR description. Reusable workflow ref is pinned to a SHA (not a mutable tag), consistent with the existing build job.

Nit: can't verify from this repo whether reusable-docker-build.yml cleanly no-ops registry/signing steps when push: false — worth a quick check in FerrLabs/.github if not already covered, but not blocking here since the observable behavior (Dockerfile lints/builds on PR, no publish) matches intent.

No blocking issues. Approving.

[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}