mica-ui: notifications settings page (/settings/notifications) #4618

Follows #4615: the Settings › Notifications page of the mica-ui app, reachable from the Settings page (System column). Reference: the Angular admin page #/admin/notifications (view) and #/admin/notifications/edit (form): eight notification kinds (network, individual study / harmonization initiative, collected dataset, harmonized protocol, file, comment, research project, contact request), each with an enable flag and an email subject, plus the contact request recipient groups.

Branch feat/mica-ui-notifications-settings.

Findings

• Everything is in the Mica configuration (GET/PUT /config, whole object replaced): is<Kind>NotificationsEnabled, <kind>NotificationsSubject (fs for the files) and contactGroups. MicaConfigDto (Mica.ts) already has every field and the system store already loads and saves the configuration: no server work.
• The legacy view shows the flags (check / empty square) and the contact groups only; the legacy form edits the subjects too, each subject input disabled when its flag is off, with a placeholder giving the default subject ([${organization}] ${documentId}: ...) and a hint listing the reserved terms (${organization}, ${documentType}, ${documentId}, ${status}, plus ${path} for the files and ${contactName} / ${contactSubject} for the contact requests). The contact groups are typed space separated in one text input.
• The texts are the config.notifications.* keys of the Angular bundles (mica-webapp/src/main/resources/i18n/{en,fr}.json); the per-kind info texts carry HTML tags (<code>, <i>).
• The server builds every document status subject from studyNotificationsSubject (EntityPublicationFlowMailNotification): the network, dataset and project subjects are stored and edited but not used by the server. Ported as is, out of scope here.
• The general settings page already has the pattern: ConfigSection (field list in view mode, edit dialog for administrators, the whole configuration saved through the system store), ConfigToggle / ConfigInput (label and hint from a config.<name> key, placeholder, disable), flagItem / valueItem / formattedItem, and the space-separated groups chips input written for the signup groups in ContentAccessSection.vue (splitGroups).

Decisions

1. One page, three ConfigSection cards grouped by topic, as the general settings page, rather than the single in-place form with save / cancel of the data access notifications: the legacy view / edit split comes for free (administrators get the edit button, other users see the values), no working copy of the whole configuration is needed, and the page looks like its sibling General page.
   • Document notifications: five toggle + subject pairs (network, individual study / harmonization initiative, collected dataset, harmonized protocol, research project).
   • File and comment notifications: two toggle + subject pairs.
   • Contact request: toggle, subject, recipient groups (chips input).
2. The view has one row per kind: a check / cross icon, then the subject when set, or the default subject greyed when the notification is enabled without one (a bit more than the legacy view, which hid the subjects).
3. The subject input is disabled when its flag is off, with the server default subject as placeholder (a code constant, as the data access panel does: the defaults are English constants of mica-core) and the reserved terms as hint. No other validation, as in the legacy form.
4. The legacy info texts are ported as plain text (HTML tags dropped).
5. The Angular config module stays untouched, as a reference.

Plan

1. mica-ui: page, sections, route and menu

• src/components/settings/notifications/notifications.ts: the kinds declared with their is<Kind>NotificationsEnabled / <kind>NotificationsSubject field names, message keys, reserved terms and default subject, and the view row of a kind
• one generic NotificationsSection.vue on ConfigSection (title, help, kinds, extra items and form slot), used by the page for the documents and the files / comments cards, and ContactNotificationsSection.vue wrapping it with the contact groups; ConfigInput takes an optional hint text (the reserved terms are a message parameter)
• the signup groups chips input extracted from ContentAccessSection.vue into a shared GroupsSelect.vue (space separated typing, pending text saved on blur), reused for the contact groups
• pages/SettingsNotificationsPage.vue: breadcrumbs (Home / Settings / Notifications), intro text, two columns of cards, systemStore.init() on mount
• route settings/notifications; Settings page entry under System with a caption

2. i18n (en / fr)

• settings.notifications / settings.notifications_caption; config.notifications.* keys ported from the Angular bundles: page title and info, card titles and infos, per kind the label, help, subject label, subject help (reserved terms) and placeholder, the contact groups label, help and form help

3. Verification

• vitest, lint, vue-tsc, prettier (no new helper, no new test)
• against the local Mica: the view values match GET /config; the documents card edited (network toggle and subject) and the contact card (groups typed space separated and committed on blur, a chip removed), saved and re-read, the rest of the configuration round tripping; the subject input disabled with its flag off; the sign-up groups input still working on the general page; the French texts; the configuration restored afterwards. The non-administrator case is the ConfigSection behaviour already verified on the general page (no non-administrator user locally)
• headless screenshots of the page and of the documents edit dialog