Wire up serverEvents capability for WASM plugins

[dirkwa]

Description:

This PR completes the serverEvents capability for WASM plugins, allowing them to receive server events and emit custom plugin events.

Changes

• Load serverEvents capability from package.json in plugin registry
• Forward server events from the app event emitter to WasmEventManager
• Add event_handler export wrapping for Rust plugins (buffer-based string passing)
• Fix subscription ID mismatch between FFI registration (packageName) and lifecycle lookup (pluginId)

Testing

The example-event-handler-rust plugin demonstrates the feature:

• Subscribes to SERVERSTATISTICS events
• Monitors delta rate against configurable threshold
• Emits PLUGIN_HIGH_DELTA_RATE alert when threshold exceeded
• Clears alert when rate returns to normal

Tested with N2K input generating high delta rates - alerts fired and cleared as expected.

[tkurki]

I started looking into this, but

• there's a bunch of totally unrelated changes afai can see, making unnecessarily hard to understand what is the actual change being added
• the core functionality is hollow - it only exposes serverevent events. events are used internally by the server for making various datastreams and event available. To be useful the feature needs to cover that mechanism and also be like the rest of SK: there's a bunch of well known events, but also dynamic, plugin contributed events

[dirkwa]

I should have mentioned it. The code I touch I use the following settings to make TS as strict as reasonable for code quality and in the preperation of autogenerated schema:

• no eslint-disable workaround
• no _prefix hiding

and comply with

{
  "extends": "@tsconfig/node20/tsconfig.json",
  "compilerOptions": {
    "outDir": "${configDir}/dist",
    "rootDir": "${configDir}/src",
    "allowJs": true,
    "typeRoots": ["${configDir}/src/types", "./node_modules/@types"],
    "resolveJsonModule": true,
    "composite": true,
    "declaration": true,
    "declarationMap": true,
    "forceConsistentCasingInFileNames": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "allowUnusedLabels": false,
    "allowUnreachableCode": false,
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    "noImplicitOverride": true
  },
  "ts-node": {
    "files": true
  }
}

[tkurki]

Every PR having unrelated code improvements is kryptonite to my throughput. Minimum is separate commits.

[dirkwa]

Making code better and more strict is never unrelated imho.

I do not really understand your strategy

• Initial WASM had to be "refactored" as it was too much commits, so I started to reduce them
• I refactor put.js -> ws.js etc. all nicely separately in PRs - than I should combine them

So the impression I got so far from you is least commits possible for a clear history.