[BUG] `discovery` prints hard-coded placeholders alongside measured values; one tool gives three different answers for ECC state; `utilization.memory` contradicts its own description

**Repo:** intel/xpumanager · **Affected:** v2.1.0 **and current `main`**
Package as installed: `xpu-smi 2.1.0+26.33.6468cec-1~26.04`.
**Hardware:** 8 × Intel Arc Pro B60 (`8086:e211`), Linux 7.0.0-31, `xe`, Level Zero 1.32.0.

## 1. Three code paths report ECC state; one of them is wrong

Reproduced on our system, three commands in a row, same device, same moment:

```
$ xpu-smi dump -d 0 --metrics ecc.mode.current --number 1
... Enabled

$ xpu-smi discovery -d 0 | grep "ECC State"
ECC State: enabled

$ xpu-smi # summary table, "Volatile Uncorr. ECC" column
| 0 Intel(R) Arc(TM) Pro B Off | 0000:18:00.0 Off | Disabled |
... Disabled for all eight chips
```

ECC is genuinely **enabled** on these cards — confirmed independently: turning it off on one
chip raised `memory.total` from **21414 MiB to 24480 MiB** (exactly 1/8 of the memory), and
the change persisted across a reboot.

The summary table is the odd one out because it never asks Sysman:

```cpp
// ial/cmn/cmd_smi.cpp:99-104
ze_device_properties_t zeDevProp = {};
if (dev->getDevProps(di->deviceHdl, &zeDevProp) == ZE_RESULT_SUCCESS) {
stats.name = zeDevProp.name;
stats.eccEnabled = (zeDevProp.flags & ZE_DEVICE_PROPERTY_FLAG_ECC) != 0;
}
```

`ZE_DEVICE_PROPERTY_FLAG_ECC` is a *capability* bit — on our hardware it is not set — whereas
`dump` and `discovery` call `zesDeviceGetEccState` and get the actual state.

⇒ One binary, one field, three paths, contradictory answers. This is reproducible on any
machine where the capability flag and the Sysman state disagree, with no special setup.

**Suggested fix:** have the summary path query Sysman like the other two, and fall back to
the flag only if that fails (as `discovery` already does).

## 2. `utilization.memory` returns occupancy, not utilisation

Description and implementation sit in the same initialiser:

```cpp
// ial/cmn/metrics/utilization.cpp:160-171
.description = "GPU memory utilization as a fraction of elapsed time memory was being read "
"or written; per tile or device, ...",
...
.getter = [](devInfo &d, MetricValue &out, const MetricCache &) -> ze_result_t {
auto *mem = d.dev->getMemory();
...
const auto r = mem->getMemoryUsed(nullptr, &val);
```

There is no time window and no pair of samples — it simply returns used memory. Measured on
our hardware, the arithmetic confirms it exactly:

```
DeviceId utilization.memory memory.used memory.total
0 0.16 % 34.234375 21414
4 0.16 % 34.109375 21414
check: 34.234375 / 21414 × 100 = 0.1599 % → 0.16
```

⇒ `utilization.memory` is a duplicate of `memory.used` expressed as a percentage, while
sitting in the `UTILIZATION` group next to metrics that do measure time-based activity.

**Suggested fix:** either implement the documented semantics, or rename the field and correct
the description.

## 3. Five `discovery` fields are placeholders printed like measurements

| field | what is actually returned | location |
|---|---|---|
| **SKU Type** | the string literal `"Production ES"`, always | `cmd_discovery.cpp:2019` |
| **Number of Tiles** | `numSlices > 0 ? 1 : 0` — always 1 | `:1663` |
| **Max Command Queue Priority** | both branches return `"0"` | `:1638-1650` |
| **Stepping** | parsed out of the model name; on a parse failure substitutes `"A0"` | `:1076-1083` |
| **Memory ECC State** (fallback) | the "device supports ECC" flag presented as "ECC is on" | `:1782-1786` |

```cpp
// cmd_discovery.cpp:2016-2020
}
// SKU type is typically derived from model name or board number
// For now, return a generic identifier based on flags
*outputLine = "Production ES";
return ZE_RESULT_SUCCESS;
```

Note the value is also self-contradictory: "Production" and "ES" (Engineering Sample) at once.
We initially took this as a statement about our boards and were preparing to raise it with the
board vendor — it is a constant in the tool.

🔑 **This is a regression, not an unimplemented field.** The 1.x line had a real
implementation — `core/src/device/skuType.cpp` (still visible at tag `v1.3.8`), with an enum
including `PCH_PRODUCTION_STATE_PRQ` and a `"Production PRQ"` return path. A user in
[#122](https://github.com/intel/xpumanager/issues/122) running `xpumcli` on the same
`0xe211` device reports `SKU Type: Production PRQ` — a genuinely read value. In the 2.x line
that module is gone and the field became a literal (verified in `v2.0.1`, `v2.1.0` and
current `main`).

**Stepping** deserves a separate note:

```cpp
// cmd_discovery.cpp:1073-1083
if (lastSpace != std::string::npos && lastSpace + 1 < modelName.length()) {
std::string stepping = modelName.substr(lastSpace + 1);
if (stepping.length() >= 2 && isalpha(stepping[0]) && isdigit(stepping[1])) {
*outputLine = stepping;
} else {
*outputLine = "A0";
}
} else {
*outputLine = "A0"; // Default fallback
}
```

Our `Device Name` is `Intel(R) Arc(TM) Pro B60 Graphics`, so the last word is `Graphics`, the
check fails, and **`A0` is printed**. All eight of our chips report `Stepping = A0`, which is
almost certainly this substitution rather than a reading.

**Suggested fix:** print `N/A` when a value is not actually available. A placeholder that
looks like a measurement is worse than an honest gap — it cannot be told apart from real data.

## 4. UUID is documented as globally unique and immutable, but is derived from the PCI address

`ial/cmn/metrics/identity.h:80-82` describes the UUID as "globally unique immutable
identifier". On our eight cards the values differ only in the PCI bus number — so moving a
card to another slot changes the "immutable" identifier, and two identical systems can
produce the same UUIDs.

Start by reproducing the reported outputs with xpu-smi dump, discovery, and the summary command, then read ial/cmn/cmd_smi.cpp, ial/cmn/metrics/utilization.cpp, cmd_discovery.cpp, and ial/cmn/metrics/identity.h at the cited locations. Trace the existing ECC, utilization, discovery, and UUID paths before deciding how the behavior should be made consistent. Done means the reported fields no longer present capability flags, occupancy, parsed fallbacks, constants, or PCI-derived values as different measurements or immutable identity.

Written by the indexing model from the issue text.