ci(freebsd): add build-freebsd job to reusable build workflow

[PR9000]

What does this PR do?

Extracted from PR #1138 as requested during review.

Adds FreeBSD 15.1 and 14.4 x86_64 build matrix legs to the reusable build workflow (.github/workflows/_build.yml).

Key details on the vmactions FreeBSD setup:

• Runner Host: Pinned to ubuntu-latest (x86_64 host). Running QEMU guest emulation on ARM runners (ubuntu-*-arm) causes severe performance degradation leading to 3+ hour timeouts.
• VM Action & Sync: Uses vmactions/freebsd-vm@v1 with sync: rsync.
• Environment Setup: Packages required for build and frontend (gmake, sqlite3, pkgconf, node22, npm-node22, bash) are installed natively inside the FreeBSD VM via pkg.
• Disabled aarch64 leg: The aarch64 leg remains commented out because lightningcss (a native Rust dependency of the Vite/CSS pipeline) does not publish prebuilt binaries for freebsd-arm64, causing npm run build to fail.

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects
  unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Accepted: FreeBSD becomes a full release target — with one stated condition, and three things to fix first.

The condition, on the record so it is not forgotten later: we will watch this across the coming releases. If the FreeBSD leg turns into a recurring source of release-day pain — mirror flakiness, VM boot failures, timeouts — we will revisit and likely narrow it to non-gating build-only coverage. That is not scepticism about your work; it is that the failure sources here are genuinely outside our control, and I would rather say now that the decision is reversible than quietly resent it later.

Full scope, since this is a CI change and I want the cost visible rather than discovered. It cannot block a PR merge — ci-ok needs only security/lint/test/changes/pr-smoke, and _build.yml is workflow_call-only. But release.yml gates smoke on needs.build.result == 'success', so a FreeBSD failure halts a release before smoke, soak and publish. Budget is up to 480 added runner-minutes worst case (two legs, 240-minute ceilings), on manual release/dry-run only. New external failure sources: the VM image download, FreeBSD package mirrors with unpinned package versions, npm inside the guest, and QEMU boot/rsync. That is the shape of the thing we are agreeing to monitor.

Three things before merge.

1. FreeBSD assets would publish without ever passing smoke — this is the blocker. release.yml sweeps artifacts with pattern: binaries-* and merge-multiple: true, so your binaries-freebsd-<arch>-<release> uploads get attached to the release. But _smoke.yml only downloads binaries-<goos>-<goarch>, binaries-windows-* and binaries-linux-*-portable — there is no FreeBSD entry anywhere. So we would ship a tarball that no lane has ever unpacked or run, and which also sits outside the VirusTotal candidate flow. Either add a FreeBSD entry to the smoke lane or exclude the artifact from the release sweep; publishing unsmoked binaries is not something I will merge.

2. Align the version interpolation with the file's own convention. The new run: body interpolates ${{ inputs.version }} directly at four sites. Every existing job in _build.yml does env: VERSION: ${{ inputs.version }} and then uses "$VERSION". The value here comes from a maintainer-only workflow_dispatch, so the practical risk is low — but the convention exists so nobody has to re-derive that reasoning per site.

3. Rebase. The branch is CONFLICTING against a base roughly two and a half weeks stale, and it pins actions/checkout@9c091bb… # v7.0.0 while the rest of the repo has moved to v7.0.1.

What you got right, and it is why this got a yes rather than a shrug. You SHA-pinned vmactions/freebsd-vm to a full 40-character commit rather than a floating tag, which is exactly what our own security-audit.sh §6 demands — and I verified that SHA still resolves to refs/tags/v1 upstream. You pinned the host to x86_64 with an in-file comment explaining that ARM runners degrade to 3h+ under emulation, and you set fail-fast: false so one OS leg cannot kill the other. Those are the decisions that separate a workable CI addition from one that becomes a permanent tax.

One thing worth both of us knowing: v1 is a tag upstream re-points, so the SHA you pinned will silently age. That is the correct trade — pinned and stale beats floating and surprising — but it means a periodic manual bump rather than never thinking about it again.

And a caveat about the green checks on this PR: they exercise none of it. Build workflows do not run on pull requests, so build-freebsd has never executed anywhere. The all-green tick means your scripts/ edits are safe on the existing platforms — and they do look safe, since $MAKE expands to make everywhere except FreeBSD and pr-smoke passes on all three OSes — but the FreeBSD job itself is unproven. The first real run will be a dry-run, and I would rather that be a deliberate step than a release-day surprise.

Fix those three and I will merge. Thank you for doing the pinning homework unprompted.

[DeusData]

@PR9000 — a nudge, since your fork's last push predates the 21 August acceptance by a few hours and I suspect it never reached you: FreeBSD as a full release target is accepted, with three fixes before merge (unsmoked-publish path, the env: VERSION convention at the four interpolation sites, rebase + checkout pin to v7.0.1). "Fix those three and I will merge" stands.

Two things have moved since that comment that you deserve to know before you start:

1. The vmactions/freebsd-vm v1 tag has already moved off your pinned SHA (83b151f5… → upstream v1 now at f0552d3b…). Your pin still resolves to a genuine upstream commit, so nothing is broken — but the "this pin will silently age" prediction from the review came true in under a week. Recommend re-pinning to the current v1 SHA during the rebase, so the periodic-bump clock restarts from a fresh point.

2. The unsmoked-publish fix is bigger on one side than the review stated. If you take the add-to-smoke path, it is not only a _smoke.yml entry: the FreeBSD artifacts also need to join the VirusTotal candidate flow, and release.yml's verify step hard-codes --expect-archives=14 --expect-binaries=14 --expect-runtime-files=42 — four swept FreeBSD tarballs change those counts. If you take the exclude-from-sweep path, the counts stay put and the job becomes build-only coverage — smaller, but it means FreeBSD binaries do not actually ship, which sits oddly under "full release target". Both shapes remain acceptable per the acceptance; the choice is yours, and now you can make it with the real costs in front of you. If you pick add-to-smoke and want the count/VT plumbing done maintainer-side while you handle the workflow half, say so — that split would be fair.

One more thing worth saying plainly: your unprompted SHA-pinning of a high-privilege VM action was the right instinct and was noticed. Same for the argued-out aarch64 exclusion. The job has still never executed anywhere — first real run will be a deliberate dry-run dispatch once this lands, per the acceptance's watch-and-revisit condition.

No deadline on this one — the acceptance is a week old and you have been consistently responsive. It is simply ready when you are.