fix(kernel): signal targeted channel revocation

[mp-blurify]

Summary

Adds provider-agnostic targeted channel revocation semantics to the first-party SSE transport. Revoked users now receive a chat:access-revoked signal before their message and signal subscriptions are removed.

Why

Private-room deletion or membership removal previously pruned the affected user’s in-process subscriptions without notifying the SSE client. As a result, the client continued treating a deleted private room as active until reload.
The implementation now:

• Notifies only the affected user.
• Does not expose the user ID to other subscribers.
• Delivers the revocation signal before pruning.
• Keeps message and signal lanes separate.
• Removes all revoked subscriptions even if a signal handler throws.
  Regression coverage verifies the transport behavior and confirms that private-room deletion and member removal invoke the revocation path.
  The change also stabilizes an existing session-expiry test by comparing timestamps using the PostgreSQL clock rather than the potentially skewed Node.js clock.

Alternatives considered

Broadcasting a revocation event to every channel subscriber was rejected because it would expose user-specific access changes to unrelated users.
Closing the SSE stream without a semantic signal was rejected because consumers need the revoked channel identifier to update local state correctly.
Implementing the behavior only in the consumer or an Ably-specific adapter was rejected because the realtime transport contract is provider-agnostic and the first-party SSE implementation must satisfy it directly.

Risks

Consumers using the SSE fallback must consume chat.streamSignals and handle chat:access-revoked to update their UI immediately. Existing consumers that do not handle the signal remain compatible but will not benefit from immediate local state reconciliation.

[zaxovaiko]

lgtm, fix conflicts, please