Isolate EventListener failures from protected application calls

[bagowix]

Problem

The protocol says listener implementations must not raise into the core, but listener hooks are invoked directly in the engine and pipeline. A bug in logging, metrics export, or a custom listener can therefore:

• replace a successful protected result with an observability exception;
• mask the dependency's original exception;
• interrupt state-transition bookkeeping;
• prevent fallback/retry behavior from completing.

A resilience primitive should not let optional observability become a new failure source.

Proposed policy

Route every EventListener callback through one shared safe dispatcher:

• catch ordinary Exception from the listener;
• log it through the stdlib interlock logger with hook and breaker/strategy context;
• continue the breaker/pipeline operation;
• never catch BaseException kinds such as KeyboardInterrupt or cancellation.

User-supplied policy callbacks that are not listener hooks (for example a tenacity before_sleep hook or a fallback function) should retain their current behavior.

Acceptance criteria

• Apply the same policy to core, storage, and pipeline listener hooks.
• Preserve backward compatibility with listeners that omit newer optional hooks.
• Add tests for successful calls, failed calls, rejections, transitions, storage degradation/recovery, retry, bulkhead rejection, and fallback when the listener raises.
• Ensure the listener failure is observable in logs and never silently swallowed.
• Document the failure policy in the observability guide and EventListener protocol.

[bagowix]

Additional scenario found while reviewing _coordination.py — listener failures are not just a hazard for the protected call, they can silently kill background work:

• _CoordinatorBase._accept → Engine._on_shared_view → _emit_transitions → listener.on_state_change(...) runs on the coordinator lane (daemon thread / asyncio task). poll_once calls _accept outside its try/except (interlock/_coordination.py:248-249, 417-418), so a raising listener propagates out of _sync_lane_tick / _async_lane_tick and terminates the lane. From then on the breaker never polls the shared view and never flushes queued writes again — with no error surfaced anywhere.
• Inside execute_op the same exception is caught by except Exception and routed to _degrade(error), i.e. a listener bug is reported to the user as a storage failure via on_storage_degraded — and if that hook raises too, the lane dies as above.

Please cover in the acceptance criteria:

• lane-side dispatch (on_state_change / on_storage_degraded / on_storage_recovered invoked from the lane) is guarded, and the lane keeps running after a raising listener;
• a raising listener is never misreported as storage degradation.