Fix building from source on Apple Silicon (arm64) and recent Clang

[M-RR-J]

Closes #69.

Summary

procgen currently fails to build from source on Apple Silicon (arm64) and on recent
Xcode / AppleClang. This PR restores the source build with a small, behavior-preserving change
set. Verified end-to-end on an M1: CoinRun creates and steps, observations are the expected
(N, 64, 64, 3) uint8 with a 15-action discrete space.

Root causes & fixes

1. -march=ivybridge is x86-only. procgen/CMakeLists.txt passes -march=ivybridge for
   packaged builds; that is an Intel microarchitecture and arm64 Clang rejects it outright. Guard
   it by architecture and use -march=armv8-a on arm64 / aarch64.
2. Qt is only probed at the Intel Homebrew path. procgen/builder.py hardcodes
   /usr/local/opt/qt5/.... Apple Silicon Homebrew installs under /opt/homebrew, so also probe
   /opt/homebrew/opt/qt@5/lib/cmake. (PROCGEN_CMAKE_PREFIX_PATH still overrides everything.)
3. Two -Wunused-but-set-variable warnings become errors under -Werror. AppleClang 21
   promotes two set-but-unused locals in starpilot.cpp and chaser.cpp to hard errors. Mark
   them [[maybe_unused]] — no game logic changes, determinism preserved.

Testing

Built and ran on:

• Apple M1 Max, macOS, Python 3.12, AppleClang 21, Qt 5.15 (brew install qt@5).
• ProcgenGym3Env(num=2, env_name="coinrun") → obs (2, 64, 64, 3) uint8, action space D15,
  stepped 50× with no errors.

Build prerequisites on Apple Silicon (workflow otherwise unchanged):

brew install qt@5
pip install -e .

Scope / notes

• Minimal and behavior-preserving. The -march change only affects packaged arm64 builds; the
  [[maybe_unused]] markers do not alter any game logic.
• Out of scope (possible follow-up): publishing prebuilt arm64 macOS wheels via the
  cibuildwheel matrix in procgen-build/. That needs arm64 CI runners and an arm64 Qt build in
  CI, which I could not validate locally. This PR restores building from source; a wheels PR
  can follow.

[M-RR-J]

Follow-up validation. I've now put this build under real load, well beyond the 50-step smoke test above. Same setup (M1 Max, macOS, Python 3.12, AppleClang 21, Qt 5.15):

• pip install . builds a working procgen-…-cp312-cp312-macosx_universal2 wheel.
• Ran a full 100M-step PPO training run on Miner using the native batched env (ProcgenGym3Env(num=64)) with an IMPALA-CNN policy on Metal/MPS — stable throughout (~2.9k env-steps/s), correct (N, 64, 64, 3) uint8 observations and rewards, no crashes or numerical issues. Trained on the 200-level split and evaluated on the full distribution, as intended.
• Also stacked an off-policy world-model experiment on top (large trajectory replay + masked-prediction transformer) — again stable on arm64.

So the source build isn't just importable — it holds up under sustained, high-throughput training on Apple Silicon.

[M-RR-J]

@hintz-openai (cc @christopher-hesse ) — apologies for the direct ping. This PR restores building procgen from source on Apple Silicon (arm64) + recent AppleClang, which currently fails outright. The change is small and behavior-preserving (an -march guard, an Apple-Silicon Homebrew Qt path, and two [[maybe_unused]] markers — no game-logic or determinism changes), and it's verified end-to-end on an M1 including a full 100M-step training run.

It's mergeable with no conflicts. Would one of you be able to take a look, or point me to whoever currently maintains the repo? Happy to make any changes you'd like. Thanks!