Device-specific, data-driven configuration (fold device table into config)

[ericfitz]

Idea

Make device support data-driven by folding the recognized-device table (currently SupportedDevices.all in Sources/FootswitchCore/FootswitchDevice.swift) into user/app configuration, so that adding a new device that uses an existing protocol is a config change, not a code change.

Potentially combine this with device-specific (and transport-specific) trigger configuration, e.g.:

"devices": {
  "fs17pro": {
    "vendorId": "0x245A", "productId": "0x8276", "program": "footswitchBLE",
    "transport": "bluetooth",
    "triggerKeys": [ { "key": "F16", "slot": 1 } ]
  },
  "fs17pro-usb": {
    "vendorId": "0x3553", "productId": "0xC100", "program": "footswitch",
    "transport": "usb",
    "triggerKeys": [ { "key": "F13", "slot": 1 } ]
  }
}

Why

• New same-protocol pedals (PCsensor and clones share the footswitch report protocol) could be supported by adding a VID/PID + program-family entry in config, without rebuilding.
• Naturally namespaces per-device, per-transport key configuration.

Relationship to current work

The FS17Pro branch implements transport-keyed trigger config now:

"triggers": { "usb": [ {"key":"F13","slot":1} ], "bluetooth": [ {"key":"F16","slot":1} ] }

This was chosen as the minimal correct fix for the per-transport programming bug (the device stores key config independently per transport; programming "the primary key" wrote the wrong key onto the BLE slot). The transport-keyed shape composes cleanly with a future devices section — device-specific config would add a layer above transport-keyed triggers.

Open questions to resolve in a dedicated spec

• Multi-device behavior: the runtime listener only sees keycodes, not which device emitted them — so per-device actions aren't directly attributable. Clarify what device-specific config controls (programming targets / device table) vs. what stays transport- or key-level (listener/actions).
• Validation/migration of a user-editable device table (malformed VID/PID, unknown program family).
• Interaction with the upcoming multi-button pedal feature (per-button key+slot+action), which also wants a say in config shape.

Deferred from the FS17Pro Bluetooth support work (transport-keyed config landed there).