ci: compile, lint, and test the level_zero backend in CI (#373)

Part A of #372. CI coverage only. Part B (shipping the feature in release artifacts) is deliberately not in this PR and stays gated on #364.

## Summary

The `level_zero` cargo feature is default-off and no CI job enabled it, so everything under `src/device/readers/intel_gpu_level_zero/` was never compiled, never linted, and its tests were filtered out of every run. Before this change, `grep -rn "level_zero" .github/workflows/` returned nothing. The module has 49 passing tests and none of them ran.

That hole has already cost something. #364's analysis attributes two of its five root causes to `intel_gpu_level_zero/apply.rs`, which no job compiles. Defects there cannot be caught by review alone when nothing else is looking.

## What changed

All in `.github/workflows/ci.yml`.

- **Linux `test` job**: added `cargo test --verbose --features level_zero` and `cargo clippy --features level_zero --all-targets -- -D warnings`.

  Both are *additional* steps rather than replacements. The default-feature build is what `cargo install all-smi` and every downstream crate without `default-features = false` resolve to, so it has to stay covered on its own.

  `--all-targets` is deliberate where the existing clippy step has no such flag: the module's tests sit behind the same feature gate, so linting only lib and bin would leave them unchecked for the second time. `cargo fmt --check` is untouched, being feature-independent.

- **`build-check`**: added a release-profile build with the feature on, so a release-only failure cannot slip past the debug-profile steps above. `--locked` is kept on purpose. `level_zero = []` activates no dependency and therefore must not move `Cargo.lock`; if that ever stops being true, it fails here rather than in the vendored Debian build, which uses the stricter `--frozen`.

- **Windows job**: added `--features level_zero`. It is the only job on a Windows runner, and `src/device/readers/intel_gpu_windows.rs` gates its Level Zero augmentation on both `cfg(target_os = "windows")` and the feature, so without the flag that code compiles nowhere in CI at all. The job is opt-in via `ENABLE_WINDOWS_SERVICE_SMOKE`, so this is coverage when the runner is available rather than a guarantee.

## Local verification

Windows 11 Pro 26200, native `x86_64-pc-windows-msvc`, rustc 1.97.1.

```
cargo test --features level_zero --lib intel_gpu_level_zero
test result: ok. 49 passed; 0 failed; 0 ignored; 0 measured; 1467 filtered out
```

```
cargo clippy --features level_zero --all-targets        (exit 0)
```

No findings in `intel_gpu_level_zero`. Six warnings are emitted, and the new step adds `-D warnings`, so each was checked against whether it can reach the Linux runner. All six are Windows-only:

| Site | Why it does not warn on Linux |
|---|---|
| `src/api/shutdown.rs:106` | carries `#[cfg_attr(not(windows), allow(dead_code))]` |
| `src/device/readers/windows_gpu_perf.rs:119` | Windows-only file, not compiled on Linux |
| `src/device/readers/windows_gpu_perf/ids.rs:52` | same |
| `src/main.rs:39` (`SocketSetting`) | consumed inside the `#[cfg(unix)]` block at `src/main.rs:311` |
| `src/main.rs:322` (`interval`) | consumed inside the `#[cfg(target_os = "linux")]` block at `src/main.rs:338` |
| `src/utils/command_timeout.rs:190` | backs two tests that are `#[cfg(unix)]`, so the import is live on Linux |

These are the pre-existing native-Windows findings tracked in #367, present with or without this change.

Also confirmed, since the build-check leg keeps `--locked`:

```
cargo build --release --target x86_64-pc-windows-msvc --locked --features level_zero   -> exit 0, 2m41s
Cargo.lock sha256 before: 6cd3928b31b8fbd079e9917c3817b16b94f15326dbaddb8eda6013683e286b32
Cargo.lock sha256 after:  6cd3928b31b8fbd079e9917c3817b16b94f15326dbaddb8eda6013683e286b32
```

Full build-chain evidence, including the PE import-table check showing no static dependency on `ze_loader.dll`, is in https://github.com/lablup/all-smi/issues/372#issuecomment-5343268371.

## What this does not do

- Does not ship the feature. Release artifacts, `debian/rules`, and the docs are Parts B and C of #372 and stay gated on #364.
- Does not change `Cargo.toml`. The feature remains default-off for `cargo build` and for library consumers.
- Does not exercise the runtime-absent degradation path inside the Level Zero code, which needs an Intel GPU host without the oneAPI runtime. That belongs to #372's acceptance criteria.

## Test plan

- [x] `cargo test --features level_zero --lib intel_gpu_level_zero` (49 passed)
- [x] `cargo clippy --features level_zero --all-targets` (exit 0; every warning traced to a Windows-only path, table above)
- [x] `cargo build --release --locked --features level_zero` (exit 0, `Cargo.lock` unchanged)
- [x] CI is the real test for this PR: the two new Linux steps and the new `build-check` leg have to go green on the runner, which is the environment this change exists to fix.

  Verified on run [32616550644](https://github.com/lablup/all-smi/actions/runs/32616550644) after rebasing onto `7472d23`. All three new steps succeeded, and the test step's numbers show the hole this PR closes:

  | step | lib / bin passed | `intel_gpu_level_zero::` tests executed |
  |---|---|---|
  | `Run tests` (existing) | 1596 / 1772 | 0 |
  | `Run tests (level_zero)` (new) | 1645 / 1821 | 49 |

  Exactly +49 in each target, matching the 49 that passed locally on Windows. `Run clippy (level_zero)` finished clean in 41.18s with `--all-targets`, which is the first time any job linted the integration-test targets, including `tests/library_api_test.rs` added by #375. `Build with the level_zero feature` passed with `--release --locked`, so the feature still does not move `Cargo.lock`.

  `Windows Service Smoke Test` remains `skipping`: the self-hosted Windows runner is down, so the `--features level_zero` change to that job stays unverified in CI, as the section above states.

Refs #372, #364