SSE push notification submodule with pluggable transports

Summary (title field):
Category (select): Feature request (plan)
Priority (select): Normal

Problem/Motivation

ACT keeps threads fresh by polling. On busy threads, polling costs server work per reader per interval, and it adds latency of up to one interval. The client already has an entry point for push. The advanced-comment-threads:changed document event makes matching placements refresh immediately, even with polling off (components/comment-thread/comment-thread.js:3222-3228; docs/api.md, "DOM events"). docs/matrix-refresh.md (around line 53) records SSE as planned, not implemented.

Proposed resolution

Add a submodule, for example advanced_comment_threads_push:

• Server side. Subscribe to the "snapshot rebuilt" event from #2, so a notification goes out after the anonymous snapshot is warm, and publish {nodeId, fieldName} on a per-host topic. The payload carries no comment content or IDs. Clients always fetch through the existing access-checked refresh route.
• Pluggable transports through a plugin type or tagged services:
  • Mercure (hub publish with JWT; subscriber topic per host/field);
  • Node.js (the existing nodejs contrib module, or a small bundled server);
  • FrankenPHP (its built-in Mercure hub).
• Client. A small library opens an EventSource per page, not per placement. It dispatches advanced-comment-threads:changed on each message. It lengthens or suspends ACT's polling timer while connected and falls back to normal polling on error or disconnect.
• Matrix freshness. Replacing the polling timer stops refresh-triggered Matrix polls (ADR 0002). Document, and optionally check in the status report, that Matrix API's cron or Drush poller, or an application server, must keep inbound messages fresh.
• Security. Topics reveal only that a host changed. Private hosts need subscriber authorization per transport, for example Mercure subscriber JWTs scoped by node access. Anonymous topics are only for hosts anonymous users can view.

Remaining tasks

• Agree the transport interface and settings.
• Implement Mercure first, as a reference, then the others.
• Journey test: a write triggers the notification, then a refresh and the arrival, with no poll.
• Load test: a 500-client burst after a write lands on a warm snapshot.
• Documentation: deployment per transport, Matrix scheduling, fallback behavior.

User interface changes

None visible. New comments arrive sooner.

API changes

• New submodule with a transport plugin API.
• The client event advanced-comment-threads:changed becomes load-bearing and must stay stable.

Data model changes

Submodule config only.

Related issues

None.