Collapse per-entry sync snackbars; removals repeat "1 entry removed" with no title

As of #23, each sync cycle with five or fewer changes dispatches one snackbar per changed entry (`src/admin/components/entry-view.tsx`, the sync-notices effect). `SnackbarList` announces every notice through `speak()`, so a screen-reader user on a busy coverage hears up to five separate announcements every poll cycle for as long as the tab stays open, with no way to mute them. The notices are dispatched without a stable `id`, so identical messages stack rather than replace.

The removed case compounds it: `getEntryNoticeMessage()` (`src/admin/utils/notices.ts`) returns the fixed string `1 entry removed` for every removed entry, so three trashed entries produce three identical snackbars — while added/updated notices show the entry title that is equally available on the removed entries.

Follow-up direction:

- Collapse notices per type (added / updated / removed) into one snackbar each, with `_n()`-based counts and a stable notice `id` so a new cycle replaces the previous notice instead of stacking.
- Give removals a title (`Removed: %s`) for symmetry with added/updated when showing individual entries.
- Consider lowering the grouping threshold, since the per-entry form is what floods the `speak()` channel.

Surfaced while reviewing #23; split out as a follow-up by decision there.

Start in src/admin/components/entry-view.tsx at the sync-notices effect, then read SnackbarList and getEntryNoticeMessage() in src/admin/utils/notices.ts. Group added, updated, and removed notices with _n()-based counts and stable ids, while individual removals include the entry title; done means repeated sync cycles no longer stack or flood screen-reader announcements.

Written by the indexing model from the issue text.