feat(notifications): coalesce owner-side comment notifications per-page

[yumike]

What

Owner-side doc-comment notifications (a new top-level comment routed to the owning group) now use a per-page coalescing scope rw:page:<siteRef>|<pageRef> instead of the per-thread rw:comment:<rootId>. A burst of new comments on one doc collapses into a single self-updating Web-inbox row per owning group, rather than one notification per thread.

Participant-side notifications (replies and resolves) keep the per-thread scope. The two namespaces are disjoint, so a reply is never swallowed by the page-level owner row.

Scope: @rwdocs/backstage-plugin-rw-backend-module-notifications only — no changes to rw-backend, rw-node, or the CommentActivity contract (which already carries siteRef/pageRef).

Why

Implements the MVP "flood fix" from the doc-comment notification design: a hot doc no longer accumulates one inbox row per comment for the owning group.

Docs

The README now documents the coalescing behavior and the optional official Slack module:

• correct config key notifications.processors.slack: [{ token }] (an array);
• group→channel / user→DM routing (which falls out for free from the existing recipient shape);
• an honest note that the Slack module does not coalesce owner-side channel posts — the per-page coalescing is a Web-inbox property. (Verified against the module source: processOptions sends channel posts with no scope; only postProcess DMs use chat.update.)

Tests

CommentNotifier.test.ts now proves the coalescing property directly (two/three top-level creates on one page → identical scope), the rootId-keying for replies/resolves, and namespace disjointness. 14/14 passing.

Verification

Verified in a running Backstage instance: as a non-owner, three top-level comments on one owned page produced a single self-updating notification for the owner (showing the latest), while a comment on a different page stayed a separate row.

🤖 Generated with Claude Code