fix(notifications): keep the egress mark from clobbering a set action

The mark named its action unconditionally, so a job that had already
named its own (the low-stock underflow branch) or a settings route
whose test then failed at the relay lost that name on the wide event.
Set the action only when the event has none, and always land the
channel and origin meta pair, through a small hasAction() on the
builder. Note the parse-time floor on the Nightscout page, which shares
the grammar.

Refs #947

docs/integrations/nightscout.md

@@ -28,9 +28,16 @@ Each entry is an exact normalized `scheme://host:port` trust unit:
   rejected;
 - approving one hostname does not approve subdomains, sibling hosts, or a
   different port; and
+- loopback (`127.0.0.0/8`, `::1`, `localhost`), the unspecified address,
+  link-local and the cloud-metadata range cannot be listed, and a listed
+  name that resolves there is refused at connect time — the grant opens
+  your network, never the container or the host it runs on; and
 - any malformed non-empty entry fails evaluation instead of silently
   weakening the configured policy.
 
+The grammar is shared with `NOTIFICATION_PRIVATE_ORIGINS`, the same grant
+for webhook and ntfy targets (`docs/self-hosting/notifications.md`).
+
 Do not put a Nightscout API token, capability URL, health data, or a URL
 containing credentials in the allowlist. Restart the application after
 changing the environment.