Show Bluetooth Alias ahead of the hardware Name

[Chessing234]

Summary

• The Bluetooth panel preferred BlueZ Name (deviceName) over Alias (name), so user renames never appeared.
• Prefer the alias, falling back to the hardware name when unset.

Fixes #9603

Test plan

• bluetoothctl set-alias "My Custom Name" then open the Bluetooth panel — custom name shows
• A device without an alias still shows its hardware name

[omarchybot]

Reviewed, and pushed one commit to your branch.

The swap itself is right, and I checked the property mapping rather than taking it on trust: in the installed quickshell 0.3.1 the generated D-Bus binding symbols map BluetoothDevice.name to BlueZ Alias and BluetoothDevice.deviceName to BlueZ Name, and org.bluez.Device(5) says applications should display Alias, which falls back to Name when unset. So name || deviceName is the correct order, and the chain cannot render a blank name: an empty or absent alias falls through to the hardware name, a whitespace- or address-shaped one is dropped by hasHumanName() (Model.js:36) before it reaches a row, and Panel.qml:997 renders "Device" rather than nothing if one ever got through.

What was wrong: test/shell.d/bluetooth-test.sh:100 pinned the old precedence.

deviceLabel(deviceRow({ name: 'Generic', deviceName: 'MX Master 3S', ... })) === 'MX Master 3S'

As pushed, the branch failed ./test/shell and so ./test/all — 29 passed, 1 failed on a clean VM.

I pushed cb830c9, which splits that assertion in two: one device with both fields pinning alias-first, one with no alias at all. The second is what the assertion's stated purpose — deviceRow carrying deviceName through to QObject-free rows — actually needs, so the coverage is kept rather than deleted. After it, on a disposable VM running the shell out of your branch: bluetooth-test.sh 49 passed, 0 failed; bluetooth-migration-test.sh 9 passed, 0 failed; ./test/cli clean. Not tested against real hardware — the VM has no Bluetooth adapter, so the panel itself was read, not exercised.

Second opinion from Codex at xhigh reasoning. It reached the same test failure independently, though its independence is not currently guaranteed, so read that as agreement. It raised two things I checked and decided not to act on:

• hasHumanName() filters on the chosen label, so an address-shaped alias would now hide a device whose hardware name is human. Not reachable in practice: BlueZ returns an address-shaped Alias only when Name is unset, and then deviceName is empty and the device was filtered before your change too. It would take someone deliberately setting a MAC-shaped alias.
• bluetoothSinkMatchesDevice() (Model.js:66) falls back to substring-matching the label against PipeWire node text when the address does not match, and bluetoothAudioSink() (Panel.qml:198) returns the first matching sink, so a short alias could claim an unrelated earlier one. Real, but a short hardware name could already do that, and a bluez sink node is named bluez_output.AA_BB_CC_DD_EE_FF.N, so the address branch answers first for the case that matters.

Waiting on the maintainer to merge. Nothing else outstanding from me.

[Chessing234]

@dhh @ryanrhughes ready for review

[Chessing234]

folding into #12114 with the other bar status fixes