Design check: Intel Arc (SYCL) backend

I am evaluating adding a fourth backend targeting Intel GPUs (Arc dGPUs, Xe iGPUs) via SYCL / oneAPI, and want a maintainer signal before investing further.

Approach

• Mirror the CUDA layout: a new in-tree candle-sycl-kernels crate holding kernel sources bootstrapped by running Intel's SYCLomatic over candle-kernels/*.cu, then hand-fixed. build.rs AOT-compiles them with icpx -fsycl, same shape as candle-flash-attn/build.rs drives nvcc.
• candle-sycl-kernels is excluded from the workspace (like candle-kernels and candle-metal-kernels), so a plain cargo build never invokes icpx and never needs oneAPI installed.
• Everything behind #[cfg(feature = "sycl")]: no new enum variants, no new trait methods, and no dependency changes for default builds.
• Small in-tree host-side FFI layer rather than a dependency on any of the (currently very new) SYCL binding crates on crates.io.
• GPU-free CI job that type-checks the sycl feature.

A compiling skeleton with these properties is working locally, and the Arc device enumerates fine (via the intel/oneapi-basekit container). I am also aware of the effort for the ROCm backend in #3801 and willing to share the common "N-th backend" plumbing if that's the correct approach.

Question

Is an icpx / oneAPI build-time dependency (isolated as above, only when --features sycl) acceptable for something you'd be willing to merge and maintain? If not, is there a form you'd prefer — e.g. prebuilt SPIR-V shipped in-tree, or runtime JIT instead of AOT?