Notification template links are dropped or lose the path prefix #27432

Eight templates take their href from a placeholder that is not part of the
notification. Seven are supplied by the web interface with the render request. One is
supplied by nobody at all.

input_failing has no case in
graylog2-web-interface/src/components/notifications/NotificationsFactory.ts, so its
link never renders on any path, the Security app welcome modal included. It is a live
type, raised from InputStateListener.java:75.

The other seven placeholders are supplied by NotificationsFactory.ts, and their
values come from Routes, which is already prefix qualified (routing/Routes.ts:440).
So those links are correct wherever that mechanism is used.

The problem is that it is not used everywhere. NotificationsResource.renderHtmlById
(/system/notifications/{id}/message/html) passes no values at all
(NotificationsResource.java:274). That is the endpoint the System Notifications
table calls, via components/notifications/hooks/useNotificationBody.ts and
SystemNotificationsTable/expandedSections.tsx. Every <#if X?has_content> guard
evaluates false, so the link is omitted with no error and no log line.
legacy_ldap_config_migration.ftl is the one exception in shape: it has an <#else>
branch, so it degrades to a link free sentence rather than a truncated one.

Result: the same notification shows a "click here" link in the Security app welcome
modal (which uses useNotificationMessage and does pass the values) and shows no
link at all in the System Notifications table.

Introduced by #26062, which added the paginated notifications resource. Before it the
notifications list rendered through useNotificationMessage.

Seven PLAINTEXT twins carry the same placeholders: all of the above except the two
remote_reindex_*, which carry no link in PLAINTEXT. These are rendered server side
with no values at all by NotificationPaginationService.java:144, where
render(notification) defaults to PLAINTEXT with values == null, and that output is
the title and description of every row in the paginated table.
NotificationSystemEventPublisher renders the same way. No client can pass values
into those paths, so the placeholders are always dropped there and need the same
server side fix.

HTML/generic_with_link.ftl:11 uses ${GENERIC_URL}. This one is not supplied by
the client. It is written into the notification details in MongoDB at creation time
by V20230629140000_RenameFieldTypeOfEventDefinitionSeries.java:142-150, as
"/alerts/definitions/" + id (the path literal itself is built at :131). That is
the only producer in either repository, and NotificationsFactory.ts has no case
for it.

Because it comes from notification.getDetails(), it is merged into the template
model on both render paths (SystemNotificationRenderService.java:90-92), so the
link does appear. But it is root relative. On an install with a /graylog path
prefix it points at /alerts/definitions/<id> instead of
/graylog/alerts/definitions/<id>, which is outside the prefix, so the user gets a
404 or the start page depending on the proxy. This is exactly
Graylog2/graylog-plugin-enterprise#13940 in a second place.

It is also persisted, so a value written before a prefix was configured stays wrong
in the database.

Reach is small in practice: one migration, guarded by publishIfFirst, and only for
event definitions missing a field name.

Four of the eight Group A types have no producer anywhere in graylog2-server or the
plugin repositories: REMOTE_REINDEX_RUNNING, REMOTE_REINDEX_FINISHED,
DATA_NODE_NEEDS_PROVISIONING and INPUT_FAILURE_SHUTDOWN appear only as enum
constants plus web interface types. Only input_failing, input_failed_to_start,
no_input_running and legacy_ldap_config_migration are raised today.

Group A:

1. Have an input that fails to start so an input_failed_to_start notification is
   raised.
2. Open System > Notifications and expand the notification row.
3. The "You can click here to solve this" sentence is missing its link.
4. Open the same notification in the Security app welcome modal. The link is there.
5. For input_failing the link is missing in both places, because that placeholder
   has no producer at all.

Group B:

1. Configure a path prefix, for example /graylog.
2. Trigger the V20230629140000 migration notification, or insert a
   generic_with_link notification with a GENERIC_URL detail.
3. Click the link. It goes to /alerts/definitions/<id>, which is outside the
   prefix.

Both groups want the same thing: build the href server side at render time from the
request scoped uri_helper that #27310 adds, rather than depending on the caller to
pass a value in or on a path stored earlier.

• Group A: replace each placeholder with a uri_helper expression in the template,
  in both the HTML and the PLAINTEXT variant, then remove the now unused keys from
  NotificationsFactory.ts. The <#else> fallback in
  legacy_ldap_config_migration.ftl can go once the link is unconditional.
• Group B: build the href from uri_helper in the template and store only the event
  definition ID in the notification details, not a path.

Whether the resolved link should be absolute or origin relative is being discussed on
#27310. Whichever shape lands there should be used here too, so the templates stay
consistent.

While touching legacy_ldap_config_migration.ftl: both of its anchors are malformed
today (<a href="${AUTHENTICATION_BACKEND}" authentication service</a>, missing the
closing >), and line 14 has a stray service<.. Worth fixing in the same pass.

Out of scope: templates that link to docs.graylog.org or to Elastic documentation.
Those are external absolute URLs and are correct as they are.