Run the unit suite before releasing, not only the installer

[darksidemilk]

Closes FOGProject/fogproject#1222

Stacked on #24. Based on gh-1220-branch-install-and-schema-matrix because both PRs edit
fogproject-tests.yml. GitHub retargets this to main automatically when #24 merges. Review #24
first; the diff here is only the last commit.

Why

stable-releases.yml's only validation between "create the release PR" and "merge and tag" was
run-install-tests. So the gate checks that FOG installs, and never that the test suite passes.

tests/run-all.sh — 43+ gates, several mutation-verified — runs on pull requests only. Anything
reaching dev-branch by another route (a direct push, the sync bot, a merge whose checks were
stale) shipped in a stable release without the suite seeing it again.

run-unit-suite goes before the install tests because it is the cheap one: minutes on a runner
against four distrobox installs.

Both inputs, and why repository is the one that matters

The three checkouts in fogproject-tests.yml were bare, which resolves to the calling
repository. From fogproject's stub that is fogproject — which is why it has always been right.
Called from stable-releases.yml, which lives here, a bare checkout resolves to
fog-workflows.

And run-all.sh over a tree with no tests/ exits 0. The gate would have reported a green
suite having tested nothing, with no error anywhere. That silent-success mode is the reason the
repository is named rather than inferred.

All three checkouts take both inputs — the schema job included — so the release call and the PR
call cannot drift into checking out different trees.

The concurrency group gains inputs.branch: without it, a release validation of dev-branch and a
PR into dev-branch share a group, and cancel-in-progress has one kill the other.

The failure path needed wiring too

Adding a gate ahead of the install tests changes what failure looks like downstream. When
run-unit-suite fails, run-install-tests and check-all-tests-completed-successfully are
skipped, not failed — and a job whose needs were all skipped is itself skipped. So
close-pr-if-tests-fail's bare failure() would never have fired: the release would stall with
its PR open and nothing announced. Worse than the case that job already handles.

It now depends on both gates and tests their results explicitly, and skips when there was no
release to make.

Its Discord message also had to move off check-all-tests-completed-successfully.outputs — that
job is skipped on the new path, and a skipped job has no outputs, so the announcement would have
named a blank version. create-release-pull-request carries the same two values and has always run
by then. The message now also names which stage failed.

Verification

• All workflow files parse. Job graph confirmed: run-unit-suite → run-install-tests →
  check-all-…, with close-pr-if-tests-fail depending on all three gates.
• All three checkouts resolve to ${{ inputs.repository || github.repository }} /
  ${{ inputs.branch }}, so a PR run is byte-for-byte unchanged (both inputs default to empty, and
  actions/checkout treats an empty ref as unset).
• Not exercised end to end — stable-releases.yml is schedule/dispatch driven and creates a real
  release PR, so a dry run is worth doing deliberately rather than as a side effect of merging.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PqufBbuckux8kitJeW3uAK