docs(debt): name the title that passes vibration mode 4

docs/dev/debt/libScePad.md

@@ -46,7 +46,7 @@
 - [scePadVrControllerReadCombinedState](../../../core/libs/prx/libScePad/Export.cpp) - the two handle arguments and 128-byte output are recovered; output field semantics remain incomplete.
 - [scePadParseUniqueDataLeonardo and the DualShock 4 queries](../../../core/libs/prx/libScePad/Export.cpp) (libScePad) - like the other pad calls, they reject the handle opened on the remote port (type 16) with `INVALID_HANDLE` (see the remote control port entry), while firmware 13.42 checks the port type stored with each handle. The behaviour comes from firmware 13.42's libScePad.sprx, read from disassembly and compared by running the firmware functions natively on random handle tables, not measured on a console. The answers follow the firmware for the one DualSense (`054c:0ce6`) reported here: scePadGetMotionTimerUnit, scePadGetMotionSensorPosition and scePadGetSphereRadius return data only for DualShock 4 models (`05c4`, `0bb2`), scePadGetBluetoothAddress only for `03d5`, `05c4`, `0bb2` and `0c5e`, and scePadParseUniqueDataLeonardo only for the Access controller (`0e5f`).
 - [scePadSetTriggerEffect](../../../core/libs/prx/libScePad/Export.cpp) (libScePad) - only the commands the trigger mask selects are checked: a selected command with a mode above 6 returns `INVALID_ARG`, an unselected one is ignored whatever it holds, and a mask bit above 0x2 returns `INVALID_ARG`. Quake (PPSA01880) and Quake II (PPSA09477) pass mask 0x2 with the left command uninitialised. Not measured on a console, including whether modes above 6 are rejected.
-- [scePadSetVibrationMode](../../../core/libs/prx/libScePad/Export.cpp) (libScePad) - modes 1 to 3 and 5 are accepted and stored. On a PS5 (firmware 13.60) the call returns `0x80920005` before `scePadInit`, then rejects a mode of 0 or below with `INVALID_ARG` before it checks the handle, and returns `INVALID_HANDLE` for a bad handle with any higher mode; whether an open handle accepts modes above 3 was not measured, since the payload could not open a pad; 5 is accepted because PPSA25286 passes it on its open handle at start-up; the meanings of modes 3 and 5 are unknown (PPSA21480 calls it with 3 right after `scePadOpen` and aborts on failure; [SharpProspero](https://github.com/SvenGDK/SharpProspero/blob/main/src/SharpProspero/Interop/Pad/Pad.cs) names only 1 and 2). The stored mode has no other effect
+- [scePadSetVibrationMode](../../../core/libs/prx/libScePad/Export.cpp) (libScePad) - modes 1 to 3 and 5 are accepted and stored. On a PS5 (firmware 13.60) the call returns `0x80920005` before `scePadInit`, then rejects a mode of 0 or below with `INVALID_ARG` before it checks the handle, and returns `INVALID_HANDLE` for a bad handle with any higher mode; whether an open handle accepts modes above 3 was not measured, since the payload could not open a pad; 5 is accepted because PPSA25286 passes it on its open handle at start-up; the meanings of modes 3 and 5 are unknown (PPSA21480 calls it with 3 right after `scePadOpen` and aborts on failure; [SharpProspero](https://github.com/SvenGDK/SharpProspero/blob/main/src/SharpProspero/Interop/Pad/Pad.cs) names only 1 and 2). The stored mode has no other effect. PPSA24779 passes mode 4, which is rejected here with `INVALID_ARG`; the console's answer for 4 is not measured
 - [scePadIsRemoteController](../../../core/libs/prx/libScePad/Export.cpp) (libScePad) - the name hashes to NID `fCWdlnmB1Ks`; the signature `(int handle, bool* remote)` comes from PPSA16064, which zeroes a byte, passes its address after `scePadGetControllerInformation` and ignores the result. The error codes follow the other pad calls. Controllers are local devices, so the answer is always false
 - [scePadIsDS4Connected, scePadIsBlasterConnected and scePadIsMoveConnected](../../../core/libs/prx/libScePad/Export.cpp) (libScePad) - the `bool (int handle)` signatures are recovered; the library reports one DualSense to every title (see Touchpad resolution below), so no DualShock 4, Blaster or Move controller is ever behind a handle and each call answers false for any handle. The console's answer for an invalid handle is not measured
 - [scePadGetParticularMode, scePadGetControllerBusType, scePadGetJackState, scePadIsControllerUpdateRequired and scePadGetContainerIdInformation](../../../core/libs/prx/libScePad/Export.cpp) (libScePad) - the console's answers are not measured; signatures, the 0x2004-byte container record and the bus values (USB 1, Bluetooth 2) come from [duaLib](https://github.com/WujekFoliarz/duaLib/blob/master/src/include/duaLib.h), which reimplements the PC `libScePad.dll`. The emulated pad reports Bluetooth, no headset (state 0), no update required and an empty container id (duaLib fills it on Windows only). A special handle and a disconnected port answer `DEVICE_NOT_CONNECTED`, as in duaLib. `scePadSetParticularMode` stores its argument for the getter and nothing else: duaLib uses it to expose the Share and PS buttons in reads, which is not modelled. The null-pointer check before the handle check follows the library's other pad queries, not duaLib