Recover from panicking notifier subscribers

[peter941221]

1. Failure mechanism

Notifier delivers subscriber callbacks from a shared delivery goroutine in deliverNotifications. Right now, one panicking callback can take down that goroutine and stop delivery for unrelated subscribers.

2. Semantic change

Wrap each subscriber callback invocation in local panic recovery.

If one subscriber panics, River now logs the panic value and notification topic, then continues delivering to later subscribers and stays alive for future notifications.

3. Why this design

This keeps the fix at the narrowest boundary that owns the risk: the callback fan-out loop.

It does not change the subscription API or the notifier control flow. It only prevents one bad subscriber from killing delivery for everyone else.

4. Testing

Added PanicInSubscriberDoesNotBreakDelivery in internal/notifier/notifier_test.go.

The test drives notificationBuf directly so it stays unit-scoped. It proves that:

• a panicking subscriber still sees the notification up to the panic point,
• another subscriber still receives the same notification,
• later notifications are still delivered after the panic.

[brandur]

Just since all notification callbacks are internal code right now, I think we might want to leave this as is — a panic would be a clear bug, and it'd be nice to know about it ASAP instead of it getting swallowed up in a test log somewhere.

[peter941221]

@brandur sure, I'll close this one.