Recognize "bmi260" as a valid IMU device name

[Rival]

Summary

Gyro stopped being detected on my Aokzoe handheld (same device as #296) after a kernel/driver update, even though the kernel-level IMU (BMI260) still works fine — /sys/bus/iio/devices/iio:device0/in_anglvel_*_raw updates correctly when moving the device.

hhd failed to find it, logging:

IMU not found for this device, gyro will not work.

Root cause

IMU_NAMES in imu.py expects the IIO device name to be the ACPI-derived string (e.g. i2c-BMI0160:00), which is what find_sensor() matches against.

However, in the out-of-tree bmi260 driver (hhd-dev/bmi260), bmi260_i2c_probe() does:

if (id)
    name = id->name;      // "bmi260", from the i2c_device_id table
else
    name = dev_name(&client->dev);  // ACPI-derived, e.g. "i2c-BMI0160:00"

Whenever i2c_client_get_device_id() resolves a non-NULL id (its i2c_device_id table only has one entry, {"bmi260", 0}), the IIO device gets named plainly bmi260 instead of the ACPI name — regardless of which ACPI ID (BMI0160/BMI0260/etc.) actually matched. This appears to depend on kernel version/i2c core behavior, which is why the same setup worked before and regressed after an update.

Since "bmi260" isn't a substring of any of ["bmi323-imu", "BMI0160", "BMI0260", "i2c-10EC5280:00", "i2c-BOSC0260:00"], find_sensor() returns nothing and gyro breaks — while the sensor itself is perfectly readable.

Fix

Add "bmi260" to IMU_NAMES so find_sensor() matches it too. Minimal, additive change; verified working on hardware (gyro confirmed functional in Steam Input after the patch + hhd restart).

Related: #296 (same device, same underlying chip mismatch, different symptom of the same fragile name-matching).