Callback Signal Registry

Implement a callback registry keyed by signal ID. Process the finite batch operations in order. Every callback ID has one row in callbackBehaviors.

Operations

• ["REGISTER", signalId, callbackId]: add the callback to that signal. A signal contains each callback ID at most once. Return ["REGISTERED"], or ["ALREADY_REGISTERED"] when it is already present.
• ["UNREGISTER", signalId, callbackId]: remove that callback identity. Return ["UNREGISTERED"], or ["NOT_FOUND"] when it is absent.
• ["SIGNAL", signalId]: dispatch the signal and return its invocation events as described below.

Registration order is significant. Removing a callback preserves the relative order of all others; registering it later appends it to the end.

Callback behaviors

Each behavior row is [callbackId, outcome, nestedSignalId, nestedSignalLimit]. outcome is "OK" or "THROW". A nested signal ID of "-" means that callback never signals another key. Otherwise, its first nestedSignalLimit invocations enqueue that signal. The invocation count is global across the whole operation batch.

A SIGNAL operation uses a FIFO queue initialized with its signal ID. For each dequeued signal, take a snapshot of its callback IDs in current registration order and invoke that snapshot completely. Nested signals join the back of the queue, so reentrant work never interrupts the current snapshot. Each later queued signal takes a fresh snapshot.

When a callback invokes a nested signal and has outcome "THROW", the nested signal is enqueued before the callback error is recorded. An error never stops the rest of the current snapshot or the queued signals.

Record each invocation as signalId:callbackId:OK or signalId:callbackId:ERROR. One SIGNAL row contains every event produced while its queue drains. Signaling a key with no callbacks returns an empty row. Return exactly one output row per input operation.