sample-notification.yaml: security scheme description and apiRoot rule mismatch

[hdamker]

Problem description

Spectral with the CAMARA r4 ruleset reports three findings on artifacts/notification-templates/sample-notification.yaml (visible in the Artifacts Lint workflow since #673):

1. Warning camara-properties-descriptions: components.securitySchemes.notificationsBearerAuth has no description.
2. Two hints (camara-api-root-default, camara-api-root-description): the template's server variable is named apiRoot, so the CAMARA apiRoot rules apply — but this server is the API consumer's notification endpoint, not a CAMARA API root. The expected standard text ("API root, defined by the service provider, …") and default (http://localhost:9091) would be semantically wrong here.

Expected behavior

1. Add a description to notificationsBearerAuth (e.g. that the notification sender authenticates via a bearer token agreed during subscription, per the Event Guide).
2. Rename the server variable from apiRoot to sinkRoot, keeping the existing consumer-oriented description. The subscription's sink (CAMARA_event_common.yaml, Sink schema) is the full absolute delivery address (format: uri, example https://endpoint.example.com/sink); in this document the conventional path /your-webhook-notification-url is appended to the server URL, so the variable holds the root portion of that address — sinkRoot, mirroring the apiRoot naming. The apiRoot rules then no longer apply, and the template no longer suggests the notification endpoint is an API root.
3. Change the variable's default from https://localhost:8080 to https://endpoint.example.com, aligning with the Sink schema's example (https://endpoint.example.com/sink): the notification receiver is the API consumer's server, not a locally runnable mock, and the reserved documentation domain signals "replace with your endpoint".

Alternative solution

Keep the apiRoot name and document the two hints as expected for this template (expected-warnings documentation issue). Renaming is preferred: the hint noise disappears and the naming is semantically clearer.

Additional context

Found while classifying the warnings surfaced by the Artifacts Lint workflow (#668).

A survey of the current API repositories (97 API definition files) shows no naming precedent to align with or conflict against: no API publishes a standalone notification-receiver OpenAPI document — notification endpoints are documented as callbacks inside the subscription APIs, addressed by runtime expressions ({$request.body#/sink}, legacy {$request.body#/webhook/notificationUrl}) without any server variable. 94 of 97 files use apiRoot as the single server variable for their own API root (remaining 3: legacy/draft specs). The name chosen here therefore sets the convention for the standalone notification document pattern.

[hdamker]

The issue description was missing when this issue was created — a slip in my tooling while posting; the full description is now in place above. Apologies to @LarryHu0217, who picked this up from the bare title in #679 — see my comment there.