fix(manager): survive Bluetooth reconnects without stale lightbar or stuck menu

[NicolasPogorzelski]

Problem

After un/re-pairing a DualSense for console use, it reconnects over Bluetooth on a
new evdev/hidraw node. Two failures followed from that:

1. Lightbar stuck on the wrong colour. It was written via raw hidraw output
   reports, which race the hid-playstation driver and get dropped over
   Bluetooth, so the pad stayed on its firmware default (blue) instead of the
   mode colour (e.g. green for Emulate-Xbox).
2. Mode switching greyed out. Instances were keyed by the evdev path, so a
   reconnect looked like a new device. The resulting tray-menu rebuild recycled
   item ids across a structural change and left the mode entries stuck disabled.

Fix

• Lightbar via the kernel LED class (:rgb:indicator) through a new,
  tightly-scoped root helper controller-led (mirrors the controller-hidraw-gate
  pattern: name/vendor validation, NOPASSWD sudoers). The driver handles USB/BT
  framing, so the colour survives reconnects. Removes the CRC / USB-BT report
  code and the persistent hidraw fd.
• Identity-keyed instances. Key by stable identity (uniq/MAC, else
  vendor:product) instead of the evdev path. A reconnect is recognised as the
  same pad and rebound in place (only the remapper restarts); a vanished pad
  is dropped only after a short grace window. A reconnect is now a no-op for the
  tray menu.

Verification

• tests/test_reconcile.py (new) asserts the reconcile decisions:
  reconnect → rebind / no menu change, blip < grace → kept, absence > grace →
  removed, distinct pad → structural change. Wired into validate-repo.sh
  (Check 7); controller-led added to the shellcheck set.
• validate-repo.sh passes; verified live: manager sets the lightbar green via
  controller-led on apply, no remapper flap.

Deploy note

Adds a root helper + sudoers line — re-run ./install.sh on the target.

[NicolasPogorzelski]

Follow-up commit 18510fa — corrects the lightbar/remap handling this branch's
first attempt did not fully solve.

Real root cause. A Bluetooth DualSense reconnects on a reused /dev/input/eventX
path (the number is recycled) while the device underneath is new: its :rgb:indicator
LED node is renumbered (name follows the inputN counter), the old remapper grab has
died, and the firmware has reset the lightbar to default blue. The reconcile only rebound
on an evdev path change, so this reconnect was missed — the pad returned un-remapped and
on the wrong colour, and the daemon kept writing the mode colour to the now-dead old LED
node (so a later mode switch changed no colour).

Changes.

• _apply_led() re-resolves the :rgb:indicator node from the live evdev path on every
  write and never trusts a cached name.
• _poll() detects a reconnect by a presence transition (previously-absent instance
  reappearing), not only a path change, and re-asserts the whole mode via rebind() one
  poll after the pad is stably present (which also makes the colour stick past the
  device/Steam bring-up).
• refresh_led() repaints when the live LED node differs from the last painted one.

Verification.

• Unit tests: test_reconcile.py scenarios A–G pass (E: node absent at bind; F: node
  renumbers on a reused path; G: reconnect on a reused evdev path re-asserts, no menu churn).
• validate-repo.sh passes.
• Live on hardware (Bazzite, DualSense over BT): repeated off/on cycles — lightbar returns
  to the mode colour automatically; journal shows gate block + remapper + the green LED
  write landing on the new node each reconnect (input60→input66→input71), no tracebacks.

Known residual. A single LED write issued at the exact instant of reconnect can still be
overwritten by Steam Input as it comes up; the re-assert one poll later is what makes it
stick, but there is no hard guarantee against Steam owning the lightbar.