ze: resolve command-queue ordinal to its engine type (fixes #506)

[DonAurelio]

Problem

Level Zero device operations are tagged with the command queue they ran on as {ordinal, index}. The ordinal alone does not say whether the queue is a compute engine or a copy engine — that mapping lives in the device's command-queue-group properties (zeDeviceGetCommandQueueGroupProperties), which THAPI did not record. So a trace could show:

zeCommandListAppendMemoryCopy(H2D)[{ordinal: 1, index: 0}]

with no way to tell it ran on the copy engine. This is #506.

Fix

1. Record a new curated event, lttng_ust_ze_properties:command_queue_group, carrying the per-device group-properties array (queried in the existing per-device property dump, reusing the already-dlsym'd entry point).
2. Resolve it in the ze interval analysis: join each op's ordinal to that array and append the engine capability flags.

The group flags field is a bitmask (COMPUTE | COPY | COOPERATIVE_KERNELS | METRICS), and several bits are typically set at once (e.g. ordinal 0 = 0x7), so every set bit is decoded into a list rather than collapsed to one type; unrecognised bits are reported as UNKNOWN.

After the fix:

zeCommandListAppendMemoryCopy(H2D)[{ordinal: 1, index: 0, flags: [COPY]}]
zeCommandListAppendMemoryCopy(H2D)[{ordinal: 0, index: 0, flags: [COMPUTE, COPY, COOPERATIVE_KERNELS]}]

Validation

Recorded two raw traces (compute ordinal 0, copy ordinal 1) on an Intel Data Center GPU Max 1550 (Aurora), then replayed the same trace files through an unmodified baseline build (before) and the patched build (after). Only the analyzer differs, so every difference is attributable to this change:

trace	before	after
ordinal 0	{ordinal: 0, index: 0}	{ordinal: 0, index: 0, flags: [COMPUTE, COPY, COOPERATIVE_KERNELS]}
ordinal 1	{ordinal: 1, index: 0}	{ordinal: 1, index: 0, flags: [COPY]}

Timings and byte counts are byte-identical before vs after (2.96us / 5.44us, 4.10kB) — the change adds a label without perturbing measurement.

Changes

5 edits, all in backends/ze/:

• ze_events.yaml — declare the new event
• tracer_ze_helpers.include.c — emit it
• btx_zeinterval_callbacks.hpp — analysis-state map (device → ordinal-indexed group vector)
• btx_zeinterval_callbacks.cpp — populate/register callback + decode flags at the emit site

Fixes #506

🤖 Generated with Claude Code

[TApplencourt]

Can you rebase? The CI should pass now.

[DonAurelio]

It seems the CI is failing now becasue I am adding a new trace point.

[TApplencourt]

Yep, no problem. Will review and merge!

[TApplencourt]

I guess at some point we may want to refactor to have always some dump_device_group_property this will allow to have cleaner early exit aka

if != ZE_SUCESS
     return
```
But good enough for now.

Thanks a lot!