[BUG] `ras::enumRasErrorSets` returns SUCCESS when the device exposes no RAS domains, so "nothing was measured" is printed as zeros

**Repo:** intel/xpumanager · **Version:** v2.1.0 (tag `6468cecb`), defect still present in
current `main` (`hal/core/ras.cpp` unchanged as of 06.09.2026)
Package as installed: `xpu-smi 2.1.0+26.33.6468cec-1~26.04`.
**Hardware:** 8 × Intel Arc Pro B60 (`8086:e211`, BMG G21), Linux 7.0.0-31, `xe`, L0 1.32.0.

> **Note on scope.** An earlier draft of this report also covered the missing
> `COMPUTE_ERRORS` category and the doubling of non-cache counters. Both were fixed
> upstream by `f43c27c2` ("ras: Consolidate RAS into ras.cpp and match sysman exp
> categories") — categories now number ten and the correctable/uncorrectable split comes
> from the RAS error set type. Only the defect below remains.

## Summary

When a device exposes **no** RAS domains, enumeration prints an error and then returns
`ZE_RESULT_SUCCESS`. The caller proceeds, iterates over zero handles, and `stats -r` prints
a full table of zeros — so "this device reports no RAS data at all" is indistinguishable
from "this device has recorded zero errors".

We hit this as users: we read a table of zeros and concluded our cards had logged no errors
in their lifetime. That conclusion was wrong.

## The defect

```cpp
// hal/core/ras.cpp:35-41
ze_result_t ras::enumRasErrorSets(zes_device_handle_t device)
{
ze_result_t result = zesDeviceEnumRasErrorSets(device, &rasCount, nullptr);
if (result != ZE_RESULT_SUCCESS || rasCount == 0) {
ERR("Failed to enumerate RAS error sets. 0x{:X} ({})\n", result, l0_error_to_string(result));
return result;
}
```

If the driver succeeds but reports zero domains, `result` is `ZE_RESULT_SUCCESS` — the
function logs an error and **returns success**. The message goes to the error log
(suppressed in normal CLI output), so nothing reaches the user.

Called from `ras::init()` (`hal/core/ras.cpp:399`), which is invoked during device
initialisation (`hal/core/device.cpp:851`).

Downstream, `getErrorsPerTile` loops `for (i = 0; i < rasCount; ++i)` with `rasCount == 0`,
touches nothing, returns `ZE_RESULT_SUCCESS` with the counter still at its initial 0, and
`cmd_stats` marks the entry valid and prints zeros.

## On our hardware

All eight B60 chips expose zero RAS domains — confirmed independently with a small Level
Zero program (`zesDeviceEnumRasErrorSets` → `SUCCESS`, `count = 0` on every device, both as
root and as an ordinary user). So the true state is "no RAS reporting available", and the
tool renders it as "zero errors recorded".

## Suggested fix

Return a distinct status (e.g. `ZE_RESULT_ERROR_UNSUPPORTED_FEATURE`) when `rasCount == 0`,
and have `stats` print `N/A` rather than `0` for categories that were never sampled.

The distinction matters most exactly when it is needed: on hardware where RAS reporting is
unavailable, the current output actively reassures the user.

Start in hal/core/ras.cpp at ras::enumRasErrorSets and ras::init(), then trace getErrorsPerTile and cmd_stats; hal/core/device.cpp shows where initialization is invoked. Reproduce stats -r on a device with zero RAS domains and verify that unsupported RAS reporting is distinct from zero errors and is displayed as N/A.

Written by the indexing model from the issue text.