fix(mappings): name the node by alias/role_id in the output selector

[ibiltari]

The cue output selector labelled every output node<N>:<name>, where N was
only the node's position in the mappings array, +1. It read neither
alias nor role_id nor hostname.

Because cuems-editor serves the controller's own default_mappings.xml as
initial_mappings and the controller is the first entry, the controller's
outputs displayed as node1: — and on a cluster whose machines are named
controller / node01 / node02 the whole numbering sits one place off:

UI node1 = controller    UI node2 = node01    UI node3 = node02

Found on the alquiler1 rental kit, where it made the Midas MR18 outputs —
physically on the controller — read as another box.

Fix

Settings already resolved this correctly in 3c37609. This applies the same
fallback chain to the selector through a shared getNodeLabel(), so both
screens name a node the same way:

private getNodeLabel(node: any, index: number): string {
  return node?.alias || node?.role_id || `node${index + 1}`;
}

formatOutputNameForDisplay gets the same treatment so the public sibling
does not drift back.

The positional number stays as the last fallback, which keeps partial
node-identity migrations safe (as cuems-frontend's CLAUDE.md promises).

Why the fields are available here

project_mappings.xsd's NodeType carries only uuid, mac, audio,
video, dmx — the on-disk mappings file can never hold identity fields.
cuems-editor merges role_id / alias / hostname in at runtime from
network_map.xml (CuemsWsServer.merge_node_data) before serving the
mappings, which is exactly what the settings label already relies on.

Scope

Cosmetic. The binding that matters is the uuid inside output_name, which
was always correct — audio declared on the controller did reach the MR18.

Built and deployed to the alquiler1 controller for verification: the label
now reads Controller:MR18 Out 1.