Forward GGML_METAL_NO_RESIDENCY env var to llama-server on macOS

[Geramy]

Summary

• Explicitly forwards GGML_METAL_NO_RESIDENCY from lemond's environment to the llama-server subprocess on macOS
• When lemond is started by launchd (e.g. after .pkg install), it does not inherit the shell environment, so the env var never reaches llama-server
• This fixes llama-server b8648 crashing on macOS CI runners (MTLGPUFamilyApple5 paravirtualized GPU) due to unsupported Metal residency sets

Test plan

• Verify macOS CI tests pass with GGML_METAL_NO_RESIDENCY=1 set in workflow
• Verify no regression on macOS when the env var is not set (normal user machines)

[Geramy]

There may not be a fix for this until we get a m series processor as a runner. See below.

- ggml-org/llama.cpp#16266 is the closest issue — Metal crashes on limited/older hardware after the "make backend async" commit. It was    
  closed with "upgrade your macOS" as the resolution.
  - PR #18738 attempted a page-alignment fix but was closed without merge. The maintainer (ggerganov) wants to find the root cause rather    
  than add a workaround, but can't reproduce it on modern hardware.                                                                          
  - No one has reported the specific issue with GitHub Actions paravirtualized GPUs (MTLGPUFamilyApple5). These aren't real Apple Silicon —
  they're VM-emulated GPUs with very limited capabilities.                                                                                   
                             
  The llama.cpp team isn't actively working on this because it only affects old macOS / limited virtualized GPUs that real users wouldn't run
   inference on. The CI runners just happen to have these fake GPUs.