fix(l0): re-initialize driver in forked child processes

[Grynder02]

Problem

fork() is broken for Level Zero on Linux when the parent has already initialized the driver. Depending on timing, a forked child either deadlocks on its first GPU call or gets 0 drivers back from zeDriverGet.

Root cause

The Level Zero loader (libze_loader, verified on 1.28.6) runs zeInit() inside a process-lifetime std::call_once. A forked child inherits the consumed once_flag and the cached ZE_RESULT_SUCCESS, so the child's zeInit() short-circuits in the loader and never calls back into this driver. The driver's existing pid-check re-init path in initDriver() is therefore unreachable after fork() — it only runs under the loader's init callback, which fires once per process lifetime of the parent.

The loader's zeDriverGet, by contrast, is a direct jump into the driver's entry point with no init logic (verified by disassembly). So zeDriverGet → Driver::driverHandleGet() is the first place the driver code actually executes in a forked child.

Evidence gathered while root-causing (strace of failing children shows zero GPU-related syscalls — no /dev/dri opens — proving Driver::initialize() never ran in the child; calling the driver's DDI tables directly, bypassing the loader, made fork work even without this patch).

Fix

1. pthread_atfork child handler (registered on first successful init): resets the driver pid and marks inherited driver handles as orphaned — they wrap DRM fds that belong to the parent.
2. Pid-change detection in Driver::driverHandleGet(): re-initializes the driver when called from a new pid, since this is the earliest point the driver can observe the fork given the loader behavior above.
3. Orphaned handles are dropped from globalDriverHandles but intentionally leaked, never deleted: the child shares the parent's DRM file descriptions, so destructor teardown (GEM close / context destroy ioctls) would destroy the parent's live GPU objects. This mirrors the pid-match policy globalDriverTeardown() already implements, and matches the leak-on-fork convention other GPU runtimes use.

Verification

Tested on Meteor Lake (Core Ultra 5 125H, Arc iGPU, Ubuntu 24.04, kernel 6.17, loader 1.28.6), built from the 26.28 source base with the same change and installed as libze_intel_gpu.so.1.15.0:

• loader-path fork test (parent inits via loader, forks 3 children, each child calls zeInit + zeDriverGet + creates a context and runs work): 3/3 children pass; before the change all children either deadlocked or saw 0 drivers
• direct-DDI fork test (bypassing the loader): 3/3 pass
• grandchild fork test (fork from a forked child): 3/3 pass
• parent unaffected after children exit (its contexts/allocations stay live — this is what the leak-don't-delete policy protects)

Honest caveats

• Developed and hardware-verified against the 26.28 release base; rebased onto current master (applies cleanly, and the symbols it relies on — initStatus, DriverHandle::pid, std::erase_if — are all present), but I have not run a full master build or the ULT suite on master.
• No new ULTs are included yet. If maintainers are interested in this direction I'm happy to add fork-simulation unit tests (e.g. pid-spoofing around driverHandleGet) — guidance on the preferred pattern welcome.
• An alternative/complementary fix would be a pthread_atfork-based reset of the call_once state in the loader (oneapi-src/level-zero); this PR fixes what the driver can do unilaterally, which is sufficient to make fork work end-to-end.