feat(executor): pass GPU device requests to spawned method containers

[Burhanuddin98]

Summary

Adds device_requests=[DeviceRequest(count=-1, capabilities=[["gpu"]])] to the client.containers.run() call in LocalExecutor. The backend itself stays CPU-only; only the spawned solver method containers receive GPU passthrough.

Motivation

The workshop methods that benefit from GPU acceleration (Hamilton's PFFDTD via the c_cuda binary, edg-acoustics' CuPy path) cannot reach the host GPU without this — the backend dispatches via the Docker socket and `containers.run()` defaults to no device requests.

What this PR does

One block of changes in `app/services/executors/local_executor.py`:

```python
device_requests=[
docker.types.DeviceRequest(count=-1, capabilities=[["gpu"]])
],
```

Verification

End-to-end run on Windows + Docker Desktop + RTX 2060 Max-Q:

• `nvidia-smi` inside the spawned method container correctly reports the host GPU.
• A GPU-compiled PFFDTD c_cuda binary (Hamilton's `fdtd_main_gpu_double.x`) executes inside the spawned container; GPU utilization tracks the kernel during the run (`~40%` on the chosen mesh).
• On a host without `nvidia-container-toolkit`, the device request is silently ignored and the container runs CPU-only — existing CPU-only methods (`pyroomacoustics`) keep working unchanged.

Open question for maintainers

`count=-1` (all visible GPUs) is unconditional here. A possible refinement is to read a per-method `requiresGpu` flag from `methods-config.json` and use `count=1` instead, sparing CPU-only methods a CUDA context reservation on multi-GPU laptops. Left out of this PR to keep the change minimal and let the design choice rest with the maintainers.

Test plan

• `nvidia-smi` inside spawned container reports GPU
• PFFDTD c_cuda binary runs to completion inside spawned container
• CPU-only method (pyroomacoustics-style) still works on the same host
• Pending maintainer review for the count=-1 / per-method-flag design choice

[mberz]

Thanks for your PR.

I've just tested it on macOS with arm and receive the following error when trying to boot the container:

backend-1 | [2026-05-12 10:53:34,419: ERROR/MainProcess] Failed to start Docker container: 500 Server Error for http+docker://localhost/v1.52/containers/8a02c31369a7b5430a1a5c42bfd9aab75ffb7561359f50eb638e5bd61e5df4d0/start: Internal Server Error ("could not select device driver "" with capabilities: [[gpu]]")

It seems that in case where gpu capability is not there, the containers fail.
Do you have a solution for that?

[Burhanuddin98]

Hi Marco, thanks for catching that on macOS arm. You were right: my "silently ignored" assumption was wrong; the daemon returns a hard 500 instead. Pushed commit 0ace611 to the same branch. It tries the GPU request first and catches the specific could not select device driver ... [[gpu]] APIError, retrying CPU-only. Any other 500 (port conflict, image pull, OOM, etc.) still propagates as before. Verified on the Linux+nvidia path that GPU passthrough still works end-to-end with the PFFDTD c_cuda binary. Ready for re-review.