rpcs3: fix stock pad binding on InputPlumber ds5 devices

[xiaodoudou]

Summary

• What is the goal of this PR? Fix RPCS3 starting with no pads bound on a fresh install of the InputPlumber ds5 devices (SM8250/SM8550/SM8650/SM8750). Since RPCS3 moved to SDL3 it opens the virtual DualSense through HIDAPI (hidraw), not evdev, and the "InputPlumber GameController" rename in gamecontrollerdb.txt only matches the evdev GUIDs. RPCS3 therefore sees the pad as "DualSense Wireless Controller 1" (HIDAPI GUID 030057564c050000e60c000000006800) and the bundled binding to "InputPlumber GameController 1" never matches. This updates the bundled Default.yml to the name RPCS3 actually sees.

Testing

• How was this tested? On an AYN Odin 2 (SM8550): stock config reproduces the empty pad list, applying this exact device string to /storage/.config/rpcs3/input_configs/global/Default.yml makes RPCS3 bind the pad and input works in game. Only fresh installs are affected either way, since the config is only copied when /storage/.config/rpcs3 doesn't exist yet.
• Test results: Pad enumerates and binds as "DualSense Wireless Controller 1" in the RPCS3 gamepad settings; buttons, sticks and triggers all respond in game.

Additional Context

• We could instead add the HIDAPI GUID to gamecontrollerdb.txt so the pad keeps the "InputPlumber GameController" name, same trick as the Edge rename in fc21904. Problem: SDL2 and SDL3 give that same GUID different button layouts (they don't even agree on whether the dpad is buttons or a hat), the db file is shared by both, and one entry can only encode one layout. Whichever SDL version the entry doesn't match gets a broken dpad, so renaming the config to the real device name is the safer fix.
• When the fleet moves to ds5-edge this line needs to follow: the HIDAPI name becomes "DualSense Edge Wireless Controller".

---

AI Usage

Did you use AI tools to help write this code? YES