ci: re-enable MetaDrive simulator driving test with log artifacts (fixes #30693)

[flowmar47]

Fixes #30693. Builds on #38283 (includes its commit — the sim camera timestamp fix is what un-breaks the test that got the job disabled with "Started to timeout recently").

What was actually wrong

The sim camerad stamped frames with eof = frame_id * 0.05s (a clock starting at zero) while everything else uses logMonoTime. locationd's filter-rewind check rejects every cameraOdometry observation against IMU time, so livePose/liveCalibration never validate, openpilot never engages, and the test rode its timeout to failure. With frames stamped from time.monotonic() (#38283), the test passes again — verified 7/8 on an M-series Mac and 2/2 in an Ubuntu 24.04 container with xvfb.

This PR

• re-enables simulator_driving (removes if: false)
• installs the metadrive fork in the job (it's currently commented out of pyproject.toml, so the job would otherwise fail at import)
• records logs during the run: SIM_LOGS=1 keeps loggerd/encoderd unblocked in launch_openpilot.sh, and the test copies Paths.log_root() out of the pytest prefix before teardown deletes it (SIM_LOGS_DIR)
• uploads qlog.zst / rlog.zst / fcamera.hevc / qcamera.ts as a workflow artifact (verified locally: all four files present and playable)

Requirements from the issue

• free runners: the job's runs-on already falls back to ubuntu-24.04 for fork PRs — this PR's own CI run is the demonstration
• real time: the bridge runs on Ratekeeper wall-clock; the 30s test drive takes ~45–70s of CI including startup
• logs as artifacts: see above
• reliability: needs repeated runs on the target runner to quantify — re-run this job as many times as you like; happy to iterate on tolerances if the free 4-vCPU runners need them

[github-actions]

Process replay diff report

Replays driving segments through this PR and compares the behavior to master.
Please review any changes carefully to ensure they are expected.

✅ 0 changed, 66 passed, 0 errors

[flowmar47]

Status after two CI runs on the free ubuntu-24.04 runner:

• setup + scons + metadrive install: ~5 min, fine
• log artifact pipeline works: the uploaded sim-driving-logs artifact contains qlog.zst, rlog.zst, fcamera.hevc, qcamera.ts from the run
• soundd fixed (runners have no audio device)

Remaining blocker, from the artifact's own rlog (managerState): modeld starts, runs for ~8s, then exits with SIGSEGV and never comes back:

t=366.3 modeld running=True  exitCode=0
t=374.3 modeld running=False exitCode=-11

The tinygrad compile3.py step for the same model succeeds during the scons build on the same runner, so it's specific to the modeld runtime path (CPU:LLVM on x86_64), not the model compile. This looks like the real reason the job was "still not ready" in February — everything else in this PR stands on its own once that's tracked down.

[flowmar47]

Root-caused the modeld SIGSEGV: the sim published tightly-packed w*h*3/2 NV12 buffers, but modeld's warp kernels are compiled against the real camerad layout from get_nv12_info() (2048 stride, VENUS-padded 4.8MB buffer for 1928x1208). The UV-plane read ran ~240KB past the sim's 3.49MB mapping — segfault on the x86 runners, silent on macOS/arm64 by allocation luck. Worse, the stride/uv-offset mismatch meant the model has been driving on a sheared, wrong-chroma image on every platform (verified by pushing a test pattern through the shipped warp pkl: packed layout smears it across rows, camerad layout keeps it intact).

Fixed in sim: publish camera frames in the real camerad buffer layout — the sim now uses create_buffers_with_sizes() with the get_nv12_info() layout. 3/3 local runs pass after the change. Also bumped Build devel to 3 minutes: build_stripped.sh needs ~70s on the free runners that fork PRs get, so every fork PR currently fails that job at the 1-minute step timeout.

[flowmar47]

Latest run (with the buffer-layout fix): build release now passes (it was the 1-minute Build devel step timeout — free runners need ~70s), modeld no longer segfaults, every process stays up, and locationd initializes (livePose.inputsOK true at t+5.5s).

The remaining gap is now purely throughput, measured from the run's own rlog artifact:

log span 61.2s, modelV2 msgs 59 (1.0/s)  # needs 20/s

tinygrad CPU:LLVM inference on the free runner's 4 vCPUs runs the driving model at ~1 Hz — 20x short of real time — so locationd's cameraOdometry freshness flaps and openpilot can't drive. Everything else on the issue's checklist (free runner, real-time bridge, qlog/rlog/camera artifacts) is demonstrated working in this PR's CI runs.

Closing that 20x gap is a modeld-runtime question (e.g. multi-threaded CPU inference or a smaller CI model), not a CI-workflow one — happy to keep pushing on it, but flagging that it's beyond workflow/test changes.