feat: Assign a unique identifier to all notification updates

[panaaj]

(Supercedes #2172) The first step on the journey to a full featured Notification API enabling centralised alert management, this PR seeks to:

1. Add a unique identifier to all notification update messages as a reference for performing actions
2. Add a status attribute to a notification value to indicate the:
   • Available actions
   • Actions taken

Goal: Introduce feature without breaking changes.

Note: SQLite requires NodeJS v22 or greater.

Scope

• Implement registerDeltaInputHandler to inspect all incoming delta Updates received by the server
• Ensure all update values with a path starting with notifications. are separated into their own Update
• Generate an uuid for each unique $source, context and path combination. Assign it to a new:
  1. Update attribute, notificationId
  2. Payload attribute id
• Add status attribute to generated notification value to indicate the available actions and actions taken.
• Process PGN126980 and align notification status with NMEA status attributes
• Implement API endpoints to test notification actions at /signalk/v2/api/notifications
• Implement SQLite store to persist identifiers after server restarts

(ref: #1560)

---

Example:

{
   "updates": [
      {
         "values":[
            {
               "path":"notifications.mob.a987be59-d26f-46db-afeb-83987b837a8f",
               "value": {
                  "state": "emergency",
                  "method": ["visual","sound"],
                  "message": "Person Overboard!",
                  "status":  {                
                     "silenced": false,     //  action taken
                     "acknowledged": false,   
                     "canSilence": false,   // available actions
                     "canAcknowledge": true,
                     "canClear": true,
                  },
                  "id": "a987be59-d26f-46db-afeb-83987b837a8f",
                  "createdAt": "2025-12-15T04:37:04.549Z",
                  "position": {
                      "latitude": 60.34567,
                      "longitude": 5.874679
                  }
               }
            }
        ],
       "$source": "notificationApi",
       "timestamp": "2025-12-15T04:37:04.549Z",
       "notificationId": "a987be59-d26f-46db-afeb-83987b837a8f"
     }
  ]
}

[panaaj]

Captured feedback from superceded PR:

• it seems the notification ids are not persisted and rebooting the server will reset everything: ids for notifications from N2K, state of manually raised notifications, zone-triggered notifications. i think they should be persisted. would this be the time to adopt node:sqlite and shoot for minimum Node 24?
• the PR has a mix of Alarm, Alert and Notification terminology in docs, filenames, code and openapi. I think we should be treating everything as notifications with different properties and adjust the terminology, unless we can come up with good reasonable definitions and semantics for the terms
• notification id not in value but in update will keep it out of the full tree. not sure what we want in this respect
• if a delta has other data in addition to a notification does this implementation split the delta in two?

[panaaj]

• notification id not in value but in update will keep it out of the full tree. not sure what we want in this respect

@tkurki I will leave it in the current location until it is determined that it should move elsewhere.
It not being in the full tree aligns with other V2 API deltas as the API is the point of management.

• if a delta has other data in addition to a notification does this implementation split the delta in two?

If you are refering to a delta Update with multiple paths, then yes the notifications are all split out and the remaining paths remain in the single update.

• the PR has a mix of Alarm, Alert and Notification terminology in docs, filenames, code and openapi. I think we should be treating everything as notifications with different properties and adjust the terminology, unless we can come up with good reasonable definitions and semantics for the terms

Agreed. The current terms used try to align with the current use of ALARM_METHOD, ALARM_STATE in Notifications but clearly there needs to be some more work on this.

[panaaj]

@tkurki Have updated terminology to be more conistent and updated both code and docs to align noting that:

• The Signal K specification uses the terms notification and alarm interchangably
• Signal K Server assigns notification deltas originating from NMEA2000 alarm PGNs with atrributes using alert.

Terminology Used:

• notification - A Signal K update delta message with a path starting with the text notifications.
• alarm - The communication of the event / condition to the operator.

[panaaj]

@tkurki Have added SQLite store to persist notification identifiers so I guess we now have a NodeJS v22 requirement!