Add Matter support (generic event-entity connection type) + IKEA BILRESA scroll wheel

[tz8]

Addresses #51 (request to add the IKEA BILRESA scroll-wheel remote) — here via Matter.

What this adds

Switch Manager currently receives events either over MQTT or from a dedicated bus
event (zha_event, deconz_event, …). Matter remotes fire neither — in Home
Assistant they surface as event.* entities, where a button press is a
state_changed and the action lives in new_state.attributes.event_type.

This PR adds a third, generic connection type keyed on event_type: state_changed,
so any blueprint can react to event.* entities. Matter is the first beneficiary,
but nothing here is Matter-specific: no new dependency, no frontend changes, and
auto-discovery works through the existing mechanism.

It also ships a ready-to-use visual blueprint for the IKEA BILRESA scroll-wheel
remote (the device requested in #51) and two small, generic blueprint-action options
that make batched scroll events pleasant to use.

Backward compatibility

• Existing MQTT and bus-event blueprints are untouched — the new branch only runs for
  blueprints that opt in with event_type: state_changed.
• The two new action options (scale_field, repeat) are optional; actions without
  them behave exactly as before.
• No changes to the frontend bundle or the stored config format.

1. state_changed connection type

• schema.py: BLUEPRINT_STATE_SCHEMA (optional state_domain, default event).
• __init__.py: blueprint schema dispatch recognises state_changed.
• helpers.py: format_state_event() flattens a state_changed into
  { entity_id, device_id, endpoint, event_type, presses, state, …attrs };
  matter_endpoint_from_unique_id() derives the Matter endpoint from the HA unique_id.
• models.py: Blueprint.is_state / state_domain; a state branch in
  create_event_listeners().

Listener scoping:

• Config path uses async_track_state_change_event scoped to the target device's
  entities (identifier = HA device_id, resolved via the entity registry; a raw
  entity_id also works). It never falls back to a global listener, so an unresolved
  device cannot become a catch-all.
• Discovery path listens to global state_changed, filtered by domain and to real
  triggers (skips restore/add) — same "press a button to discover it" UX as zha_event.

2. Two optional action options for batched events

Matter batches fast scrolling into a single multi_press_N event (N = notches, capped
at 8), unlike Zigbee which sends one event per notch. data.presses (parsed from
multi_press_N, else 1) exposes the count, and actions can use it without the end
user writing templates:

• scale_field: <field> (string or list) — runs the action once with the named
  service-data field(s) multiplied by data.presses. The BILRESA rotate actions use
  scale_field: brightness_step_pct, so a fast flick dims by step × notches in a
  single, race-free light.turn_on (repeated relative steps otherwise read stale
  brightness and don't accumulate). Scaling runs on a deep copy of the raw sequence,
  is type/sign preserving, leaves templates untouched, and never mutates the original.
• repeat: <data-field> — runs the action's sequence N times (clamped, sequential).
  Better for discrete actions (scenes, counters, media next).

3. IKEA BILRESA blueprint (visual)

matter-ikea-bilresa-scroll-wheel.yaml (+ image). This is a visual blueprint: it
ships a transparent device photo with three positioned circular button regions (using
the blueprint circle shape), which the editor renders as clickable, colour-highlighted
markers (selected / pressed) — the same image-based style as the visual blueprints in
the repo, not the image-less list style.

The remote's three lower LEDs select one of three modes (pressing the lower part only
cycles the LED and emits no HA event); each mode exposes the same wheel gestures as
Matter generic-switch endpoints. The three buttons are the three LEDs (left = LED 1,
middle = LED 2, right = LED 3), each with six actions: press / press 2x / hold /
hold (released) / rotate right / rotate left. Matching uses template conditions on
data.endpoint / data.event_type.

Testing

Verified on a live BILRESA over Matter. Auto-discovery finds the device, and all nine
endpoints (three LEDs × rotate right / rotate left / press) route to exactly the right
action across all three modes. Rotate dimming scales correctly — the debug log shows e.g.
Running scaled sequence (x7) for a fast flick, while press actions run unscaled.

Notes

• The BILRESA endpoint→gesture numbering follows the common layout; if a unit differs,
  the monitor shows the real endpoint and the blueprint conditions can be adjusted.
• hold / hold (released) are wired up but depend on the device emitting
  long_press / long_release; where unsupported those tabs are simply inactive.
• The device image is 339×500 (within the 800×500 guideline); the three LED circle
  buttons are positioned over the LED dots and highlight on select/press.
• If you'd rather review this in smaller pieces, I'm glad to split it into (a) the
  state_changed connection type, (b) the scale_field/repeat action options, and
  (c) the BILRESA blueprint.

Blueprint Checklist

• You viewed the README and conformed to the naming conventions
• You ordered the actions as stated in the README action order
• All filenames are lowercase and uses '-' for spaces and not '_' while using {service-name}-{switch-name-or-type}.yaml format
• Images are png
• Image backgrounds are transparent and is cropped to the device boundaries
• Images has a maximum width of 800px and maximum height of 500px
• There are no missing buttons or actions
• Your integration/service is running on the latest version
• You have tested your blueprints and made sure each button and action works

Zigbee2MQTT

• (older devices) You have ensured legacy is off/false for the device in the Z2M devices Settings (specific) page and that your actions matches those with legacy off?

N/A — this device is added over Matter, not Zigbee2MQTT.