ci: add a macOS build + install + link job

[vejeta]

What

Adds a macOS CI job: build on macos-14, make install into a prefix, then
link a tiny downstream against -lX11 -lXft -lXext to prove the installed
standard-name aliases and rpath resolve the way a consumer sees them (e.g. a
native app built with --with-libx11-compat=$PREFIX).

Why

The shim exists to run X11 apps natively on macOS, but all current CI is
ubuntu-24.04, where the native paths are compiled out -- so nothing gives an
automated signal that a change still builds and links on macOS. As a concrete
example, this job asserts that make install's .so aliases resolve under
-lX11 on macOS (they do -- verified by hand -- but no CI proves it today).

Notes

• Deliberately minimal (one runner, SDL3 backend). Happy to extend to a matrix
  (macos-13 x86_64), make check, etc. if you want.
• I cannot run macOS Actions locally, so this PR's own CI run is the
  validation -- the job may need a tweak or two.
• This is a proposal for your call: if you would rather not spend macOS runner
  minutes here, feel free to close it, no attachment.

---

Summary by cubic

Adds a macOS CI job on macos-14 that builds, installs to a temp prefix, and links a tiny probe against -lX11 -lXft -lXext. Cancels superseded PR runs; scope is X11/Xft/Xext only due to missing <X11/Xpoll.h>.

• New Features

  • Installs sdl3, sdl3_ttf, pixman, pkgconf via Homebrew.
  • Builds with SDL_BACKEND=sdl3, installs to $RUNNER_TEMP/prefix using XCOMPAT_INSTALL_ALIASED="X11 Xft Xext".
  • Links a C probe and verifies with otool -L that it resolves to the shim.

• Refactors

  • Uses actions/checkout@v7; untaps aws/tap to silence Homebrew’s trust notice.
  • Adds a concurrency group to cancel superseded PR runs (never on main).

^{Written for commit 62b38e6. Summary will update on new commits.}

[vejeta]

CI is green on macos-14. The link step proves the path end-to-end: make install creates the .so aliases and a downstream links -lX11 -lXft -lXext cleanly, with otool -L showing @rpath/libX11-compat.so / libXft-compat.so / libXext-compat.so and no /opt/X11.

Separate finding while wiring this up: building the full Xt/Xmu/Xaw alias set on a clean macOS runner fails at libXt with X11/Xpoll.h not found -- it is taken from a system copy that a runner without XQuartz does not have. I scoped this job to the X11/Xft/Xext native-app core (what a native GUI links) rather than pull a libXt fix into a CI PR. Happy to file a separate issue/PR for the libXt-on-macOS header if you would like it covered.