Config change event mishandling #8

What happened?
Since version 2025.1.0, EVENT_CONFIG_CHANGE is not reliably broadcast. Users must explicitly configure it as a broadcast event, otherwise the first listener that acknowledges it prevents further propagation. This behavior breaks expected functionality for multi-listener scenarios.

How can we reproduce the issue?
Steps to reproduce the behavior:

1. Register multiple listeners for configuration changes.
2. Trigger a config change event without marking it as broadcast.
3. Observe that only the first listener processes the event, others are skipped.

Relevant log output

N/A

Operating System

N/A

Project Version

2025.1.0 (first release with this behavior)

Expected behavior
EVENT_CONFIG_CHANGE should always be broadcast, ensuring all listeners are triggered. Alternatively, Nano should never acknowledge this event type, which could be cheaper than enforcing a broadcast check on every event creation.

Screenshots
N/A

Additional context