ci: add self-hosted macOS HVF runtime job

[Max042004]

GitHub-hosted macOS runners do not expose Apple's Hypervisor.framework (HVF):
the hosted runner OS itself runs inside a virtualization layer that withholds
HVF, so hv_vm_create() returns HV_UNSUPPORTED. Because of this, the existing
build-macos job can only compile elfuse and verify the HVF entitlement — it
can never actually boot a guest.

This PR adds a runtime-macos job that runs on a self-hosted Apple Silicon
runner (an M4 machine) where HVF is available, so the real runtime path —
booting a Linux guest under HVF + Rosetta — is exercised in CI for the first
time. The hosted build-macos job is unchanged and keeps gating builds as
before; this job runs after it (needs: build-macos).

Closes #51.

What the runtime-macos job does

• runs-on: [self-hosted, macOS, arm64], needs: build-macos, 60-minute
  timeout.
• Per-ref concurrency: cancels in-progress runs for the same PR, but lets
  main runs finish.

Where it runs (trigger gating)

The job is fenced by:

if: >
  github.repository == 'sysprog21/elfuse' &&
  (github.event_name == 'push' || github.event_name == 'pull_request')

github.repository is the repository the workflow actually runs in, so this
single check expresses exactly when the physical runner should be used:

• PR targeting main — runs. A pull_request from any fork is evaluated
  in the upstream (sysprog21/elfuse) Actions context, so a collaborator who
  pushes a branch to their own fork and opens a PR against upstream gets the
  full runtime suite. This is the normal contributor flow and must work.
• Push to main — runs. Post-merge validation on the mainline.
• Activity in a fork's own context — skipped. Pushing a branch to a fork
  without opening an upstream PR (or a fork's own workflow_dispatch) runs in
  the fork's context, where github.repository is the fork, so the job is
  skipped and never queues against a runner the fork doesn't have.

Note this intentionally does not use a head.repo == base.repo guard
(which would reject every collaborator PR, since those come from forks) and does
not require a ci-hvf label. The trust boundary for untrusted outside
fork PRs is the repository setting Settings → Actions → General → "Require
approval for all outside collaborators" (or stricter): such PRs cannot start
any workflow run until a maintainer approves them. A maintainer reviewing the
diff before approving — and never approving fork PRs that touch
.github/workflows/ — remains the real gate, exactly as
pull_request_target / workflow_run are avoided here.

Steps, in order

1. Host info — sw_vers, uname -a, sysctl kern.hv_support, assert the
   host is arm64.
2. Cache + install Homebrew packages (binutils, qemu) — only installs
   what is missing.
3. Tool versions — make / objcopy / qemu-aarch64 / python3.
4. Check Rosetta for Linux — verifies
   /Library/Apple/usr/libexec/oah/RosettaLinux/rosetta exists; if not, it
   emits a ::error:: with the exact install command and dumps the oah
   directory to aid debugging.
5. Build elfuse (make elfuse).
6. Verify the HVF entitlement is embedded in the binary via codesign.
7. Run the runtime tests: make test-hello, make test-multi-vcpu,
   make check, then the full bash tests/test-matrix.sh all matrix.

[jserv]

Improve Git commit messages to properly describe changes related to the self-hosted macOS runner.

[jserv]

Refine the descriptions of both pull request body and commit message to address the close of #51 .