feat(notifications)!: replace Notifications 1.0 with persistent notifications

[hmans]

Why

Notifications 1.0 coupled attention, handling, and deletion: opening or dismissing an item removed it, and users could not retain read items. Notifications 2.0 replaces it with a persistent notification list whose attention state is independent from deletion.

Closes #1556.

What

• replace Notifications 1.0 with deterministic per-recipient notification occurrences in RUNTIME_STATE, with a 90-day absolute TTL
• expose one chronological list containing both Unread and Read notifications; read rows remain visible but subdued
• group the list into Today, Yesterday, This Week, and month sections using each account's preferred time zone
• render full localized activity sentences such as “Bob has sent you a direct message.”
• mark an unread notification Read only after its target message is displayed successfully
• make permanent Delete the sole explicit row action; there is no Done, Restore, Mark Unread, or Save operation
• optimistically delete individual groups and restore them when the server rejects the mutation
• add an optimistic Dismiss All action backed by one authoritative request per authenticated server, with per-server rollback on partial failure
• use the semantic notification-orange attention colour for unread rows and indicators, and show bell/server attention whenever at least one unread notification exists
• render streamlined clickable rows with pointer cursors, a framed trash button, uncluttered metadata, and no per-row count badge
• coalesce list invalidations so initial load performs one list request per authenticated server; preserve fulfilled results when another server fails
• make the shared durable notification consumer the sole occurrence/lifecycle writer; request paths wait for its acknowledged EVT boundary and fence their local occurrence index when freshness matters
• protect delayed work with durable visibility and read boundaries, using EVT stream order rather than wall-clock timestamps
• reconcile implicit visibility loss from universal-room, room-group placement, room-ban, and relevant RBAC/role facts through a snapshot-capable exact-boundary projection
• keep configured-email owners and event-time visibility aligned by durably retrying owner-role materialization after verification
• validate exact target/reaction visibility after capturing and waiting recipient, server-wide room-event, room-group-layout, and RBAC projection tails
• capture and wait the current config tail on every source OCC attempt before evaluating notification policy; retries recompute recipients, policy, and prepared work
• fence Alert claims and occurrence mutations behind the existing durable notification worker without adding fence events
• preserve thread roots for reaction targets so notification navigation reaches the exact thread and event
• support per-cause Off/Badge/Alert policy at server and room scope for causes that have real producers
• expose single-occurrence, group, and whole-list deletion
• keep EVT limited to domain-changing facts: Notifications 2.0 adds no occurrence, candidate, plan, revocation, authorization-fence, or worker-trigger events
• remove all Notifications 1.0 services, handlers, stores, settings, live behavior, generated clients, tests, and documentation
• update generated ConnectRPC references, ADR-071, ADR-072, FDR-012, related feature records, the glossary, release notes, and the runtime architecture inventory
• strengthen the event-sourcing guidance: a new EVT type is a last resort for a domain-changing fact, not an outbox or worker trigger

API and compatibility

• Breaking public API change: Notifications 2.0 replaces the legacy notification RPCs and the earlier in-PR Inbox/Done API with one list, MarkNotificationRead, and delete operations. The PR carries the api-breaking-change label.
• NotificationOccurrence.unread is the public attention state; the public Inbox/Done enum, view filter, general occurrence update, and group-state update are removed.
• DeleteAllNotificationOccurrences is additive within the Notifications 2.0 API. It deletes the occurrence set current at the authoritative mutation boundary; clients must not automatically retry after an ambiguous failure because later activity can arrive after that boundary.
• Notifications 2.0 is the sole supported notification implementation. Existing Notifications 1.0 records are not migrated, translated, dual-read, or exposed through a compatibility adapter.
• The persisted core state retains the old numeric DONE enum value for protobuf/storage compatibility. Current code treats it as read and never writes it.
• The bundled 0.5.0 client/server version gate rejects a new client connected to an older server. External integrations must regenerate clients for the replacement NotificationService methods.
• During a rolling upgrade, old replicas can still write only legacy records; new replicas do not translate them. Notifications 2.0 becomes consistent once all writers are upgraded.

Verification

• merged current origin/main (2b3b18736)
• mise codegen-proto
• mise test-cli
• mise test-frontend (125 server files / 1,137 tests; 159 client files / 1,596 tests; 60 Storybook files / 180 tests; performance comparison passed)
• mise lint-frontend diagnostics passed; focused ESLint passed after the final Svelte reactivity fix
• production frontend build and bundle budgets
• mise license-check
• notification E2E: 33 passed before this UI follow-up; the changed interactions have focused browser-component coverage
• Chrome DevTools verification: localized full-sentence rows, Today heading, notification-orange unread styling, Dismiss All button styling, immediate optimistic removal under Slow 3G, and one bulk-delete request followed by one reconciliation list request