sim: fix macOS MetaDrive support

[zgohr]

Fix MetaDrive simulator support on macOS. Two issues prevented the simulator from running:

1. processNotRunning errors: logcatd and proclogd are Android-only processes that trigger engagement-blocking errors on macOS. These are now blocked in the simulation launch script.

2. CoreFoundation fork crash: After the Qt→raylib UI migration, os.forkpty() in unblock_stdout() crashes on macOS because CoreFoundation/AppKit doesn't allow fork() after initialization. This is now skipped on macOS.

Related bounty: Get MetaDrive simulator working on macOS

Verification

Tested on macOS 14 (M3):

• MetaDrive simulator launches successfully
• openpilot UI displays correctly with BIG=1
• openpilot engages and drives in simulation
• Verified simulation completes laps without crashes

Known Issue

Camera view has a rendering artifact (diagonal distortion in corner) - this is an upstream panda3d/MetaDrive issue on macOS, not an openpilot bug.

[github-actions]

Thanks for contributing to openpilot! In order for us to review your PR as quickly as possible, check the following:

• Convert your PR to a draft unless it's ready to review
• Read the contributing docs
• Before marking as "ready for review", ensure:
  • the goal is clearly stated in the description
  • all the tests are passing
  • the change is something we merge
  • include a route or your device' dongle ID if relevant

[adeebshihadeh]

why? i believe this used to work

[zgohr]

The issue is described here: #36785

[adeebshihadeh]

oh i see the issue, but why does it happen now?

[zgohr]

MetaDrive's raylib initializes AppKit before manager.py runs. unblock_stdout() then calls os.forkpty(), which triggers macOS CoreFoundation's fork safety crash (can't fork after Cocoa init). Doesn't affect on-device since no GUI frameworks are loaded before manager starts.

The Objective-C runtime can't be both thread-safe and fork-safe. After AppKit/CoreFoundation initializes, it may have threads running or state that can't be safely duplicated via fork(). Apple's solution: crash with the message:

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().

The rule is: after fork(), you must immediately exec() a new program (which replaces the process image). But os.forkpty() in unblock_stdout() forks and continues running Python in the child — no exec().

Workarounds:

• spawn instead of fork (what multiprocessing uses by default on macOS now)
• OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES env var (must be set before process starts)
• Or just skip the fork entirely on macOS (what my fix does)

My fix is cleanest approach since unblock_stdout() isn't critical, from what I can tell. Even from looking back at the git history, it's not clear why it's there in the first place. But take for instance it's there to potentially speed up on-device logging pipelines; since the sim runs in terminal, blocking shouldn't be a concern.