Qwik signal-driven alerts: scoping updates without notification noise

I'm designing an alert system in a Qwik application where multiple independent UI regions (header badge, toast area, per-widget indicators) need to react to alert state. The goal is that each alert signal updates only the components subscribed to it, so a single alert doesn't cause unrelated regions to re-render or flash redundant notifications.

My uncertainty is around the right granularity and lifecycle. I can model alerts as one shared useSignal holding a collection, or as several scoped signals per region. The shared-collection approach is simpler, but I'm unsure whether Qwik's fine-grained reactivity still prevents subscriber re-renders when only one item in the collection changes, or whether mutations to a signal wrapping an array/object re-notify every subscriber. I'm also unsure how this interacts with Qwik City route actions delivering server-driven alert payloads, and whether error boundaries fully isolate alert display failures without disturbing resumable state elsewhere.

Assume Qwik 1.x unless behavior differs meaningfully across versions.

1. Does updating one item inside a signal-held collection re-render all subscribers, or only those reading the changed item?
2. Is per-region scoped signals the documented pattern for isolating alert updates, or is there a recommended store-based approach?
3. What cleanup is required in useTask so alert subscriptions don't leak or double-fire across navigation?