Feature: standalone NotificationTemplate provisioning

[busehalis-sap]

Standalone Notification Template Provisioning

What
This PR introduces standalone notification template provisioning. Previously, templates were embedded within notification types. This PR adds the ability to manage them as separate, standalone objects via a dedicated NotificationTemplateProviderService endpoint. The embedded approach still exists as an alternative, but the standalone mode enables additional capabilities such as customer customization.

Based on the Notification Templates API.

Why
Separating templates from types enables customers to customize notification templates independently (e.g. adjusting subject, body, or translations) without modifying the notification type itself.

Key Changes

• New NotificationTemplateProviderService as a remote service for standalone template CRUD operations
• NotificationTemplateAutoProvisionerHandler for both production and local modes, handling automatic template provisioning on application startup
• NotificationTemplateBuilder for constructing template payloads from CDS model annotations
• I18nHelper extracted as a utility for resolving i18n bundles across locales
• @notification.customizable annotation to control template visibility in the Work Zone admin UI. When set to true, the template appears in the admin interface and can be edited by the customer. When false, it remains hidden and only the developer-defined version is used.
• Reduced log verbosity (per-item logs moved from INFO to DEBUG)
• Integration & unit tests covering template provisioning, re-provisioning (update), local mode, and I18nHelper

[Schmarvinius]

NotificationTemplateBuilder and NotificationTypeBuilder have a big overlap

• Scan model.events().filter(event -> event.findAnnotation("notification.template.title").isPresent())
• Iterate over i18nHelper.getAvailableLocales()
• Resolve the same annotations (notification.template.title, notification.template.subtitle, etc.)
• Load HTML from classpath with the same logic
• Extract the same source name from qualified name

Maybe think of a shared base or shared "event scanner"

--

Also, you have 3 classes that are in the handler package which are not handlers but helpers. Why not move them in the appropriate package?

[busehalis-sap]

Thanks for the feedback! @Schmarvinius

You're right that there is structural similarity between NotificationTypeAssembler and NotificationTemplateAssembler. However, they serve fundamentally different purposes and produce different output types:

• NotificationTypeAssembler builds embedded templates as part of a NotificationType, mapping to fields like TemplateSensitive, TemplatePublic, TemplateGrouped
• NotificationTemplateAssembler builds standalone NotificationTemplate objects with a completely different ANS API structure (Translation.Title, Translation.Body, Tags, PropertiesSchema, Visibility)

Merging them into a shared base would couple two distinct ANS API concepts. Also, the embedded template approach (NotificationTypeAssembler) is planned to be deprecated in a follow-up PR once standalone templates are fully adopted, at which point this overlap disappears naturally.

Note: Also renamed both classes to Assembler as per your suggestion.