config diff reports false-positive changes when control titles are duplicated

[tobsch]

Problem

blocks info returns an empty inputs array for blocks that clearly have inputs.

Repro

lox-cli blocks info LightController2 -o json
# → "inputs": []   (but the block has I1..I8, Move, Presence, EnMove, InputDisable, Sel1..Sel8, …)

outputs and parameters are populated; only inputs is empty (at least for LightController2 — worth auditing others).

Expected

inputs should list the block's input connectors.

Impact

Anyone using blocks info to classify connectors (e.g. to render/lay out or validate wiring) gets wrong data and must fall back to deriving inputs from the wiring graph.

---

Found during an agent-driven analysis session (Claude Code) building multi-room logic on a real config.

[tobsch]

Correction to my own diagnosis — after reading the code, diff_configs already matches controls by UUID (for (uuid, entry) in &new.controls { match old.controls.get(uuid) … }), not by title. So "match by UUID instead of title" is not the fix; the report was wrong on the mechanism.

The false positive is real (verified: the reported room is identical in both files via config controls), but the cause is elsewhere — most likely in how parse_config_summary builds the controls map (e.g. two <C> sharing a UUID collapsing in the HashMap, so re-serialisation flips which one wins) or a room-resolution difference between config diff and config controls. Would need a minimal repro to pin down.

Leaving the issue open but re-scoped: investigate the source of the false-positive change report (summary map / room resolution), not the matching key. Sorry for the initial mis-scope.