[RaRaiRen]

What changed

Two identical RGB RAM sticks (ENE DRAM over SMBus) could not be controlled separately, and Hand back only released the first one.

OpenRGB reports no serial for SMBus controllers, so deviceKey gave every matching stick the bare name ENE DRAM. They shared one lighting.json entry, and findLive resolved that key to the first stick only. Release, set, follow and save all reached one stick. The second stayed on the last frame Ryoku pushed. ENE DRAM modes can't be saved and a warm reboot keeps the controller powered, so it stayed stuck across reboots.

This PR:

• Keys a serial-less device with an OpenRGB I2C location (I2C: <adapter>, address 0xNN) as Name#smbus:<adapter>@<address>. The /dev/i2c-N node is removed from the adapter name because the bus number follows driver load order and can change between boots. The adapter name and address stay put. Serial-less USB devices are unchanged, since their path moves.
• Migrates the old bare-name entry through the existing alias path in rememberFirstSight. Each stick it stood for gets its own copy, and the legacy entry is removed only after all of them have claimed it, and never while a live device still uses that key. Previously an alias was moved by pointer and deleted on first claim, which would have given only one stick the user's settings.
• Sorts identical names by key, so the two cards keep their order between scans. The card subtitle already shows the location, so the sticks are distinguishable in the picker with no QML change.

I left the general case alone: two identical USB devices with no serial still share one entry, and findLive still returns only the first. Making a shared entry drive every match would touch apply, follow, save and the animator, so it seemed worth a separate discussion.

Area

ryoku

How it was tested

• go build ./... && go vet ./... && go test ./... in ryoku/hub/backend: all pass.
• New tests: TestDeviceKeySeparatesIdenticalSMBusSticks, TestFirstSightGivesEverySharedStickItsOwnCopy, TestReleaseRestoresOnlyTheChosenStick. The last one drives lightingRelease through the fake SDK connection from openrgb_test.go. All three fail on the old code; the release test reports restore went to device 4 (packet 1101), want 7, which is the reported bug.
• Live, on an ASUS X870 with two ENE DRAM sticks at 0x71/0x73 on SMBus PIIX4 adapter port 0 at 0b00 (/dev/i2c-8), OpenRGB 1.1:
  • Installed 1.0.7 (f7197d7): ryoku-hub lighting release "ENE DRAM" exits 0, but only 0x71 returns to its restore mode; 0x73 stays in Direct.
  • Patched binary against the live SDK server, with a copy of the real lighting.json (XDG_CONFIG_HOME pointed at a scratch dir): lighting scan lists ENE DRAM#smbus:SMBus PIIX4 adapter port 0 at 0b00@0x71 and ...@0x73 and splits the old shared entry into both, each keeping managed, mode and restore. Releasing the 0x73 key leaves 0x73 unmanaged and 0x71 still managed, with no error.
• Not tested: the picker UI with the patched backend (I didn't deploy it over the packaged ryoku-hub), and SMBus GPU or motherboard controllers, which share the location format.

Checklist

• One logical change, with a clear [area] scope: summary commit subject.
• Matching CHANGELOG.md updated in the area I touched.
• The git hooks pass locally; I did not use --no-verify.
• Lua parses (luac -p), shell scripts pass bash -n, and QML passes
  qmllint where applicable. (Go only.)
• No duplicated config, no dead code, no commented-out code, no em-dash.
• Docs updated if behavior or layout changed. (No doc describes the key format.)