Improve scalability of activity/notification fan-out for large shares and frequent updates

This issue is partially related to https://github.com/nextcloud/notifications/pull/2897 but with more context.

Problem

There are several scalability and UX issues in the current activity/notification model when a file is shared with large groups or updated frequently.

Scenario 1: Duplicate activity entries for group shares

If a file is shared with a team/group of 50 users, every file change creates 50 separate activity records (one per user).

This causes:

• excessive database growth,
• redundant duplicated records,
• inefficient activity storage.

A possible optimization would be to store a single activity entry for the group/share target and resolve visibility dynamically when rendering the activity stream.

However, there are some non-trivial edge cases:

• nested groups,
• users belonging to multiple groups that have access to the same file,
• preventing duplicate entries in the activity feed.

Scenario 2: Synchronous fan-out is slower than the main action

When an entity (for example, a file) is shared with many users or a large group, writing activity entries and notifications can take longer than the actual primary action (saving/updating the file) 🙈.

This becomes especially noticeable for large shares.

Would it make sense to move activity/notification fan-out into background jobs (queue-based processing), so the main user action completes faster?

Scenario 3: Excessive noise from aggressive autosave (Collabora)

With aggressive autosave settings in Collabora Online (for example every 60 seconds), each save generates:

• a new activity entry,
• a new notification for every user with access.

This creates a lot of noise and can quickly flood activity feeds and notification centers.

Possible improvements:

• rate limiting similar events,
• aggregation ("Document X was updated 15 times in the last hour"),
• debounce windows for repetitive updates.

Expected outcome

A more scalable and less noisy activity system for:

• large group shares,
• high-frequency collaborative editing,
• reduced DB pressure,
• better user experience.

Let's think/discuss together how can we improve that. I can participate in some of that improvements as well (but let's agreed on solution first)

Start by reading the related notifications pull request #2897 and the activity and notification fan-out paths, which are not identified in the issue. Compare the three scenarios and clarify which one is in scope before proposing an implementation. Done should mean an agreed solution with measurable improvements for large shares, frequent updates, and database or feed noise, backed by relevant tests.