[Real-time collaboration] Refine collaborator overlay with Avatar component integration

[dabowman]

What?

Refines the real-time collaboration (RTC) cursor overlay and presence indicators in the editor by integrating the new Avatar and AvatarGroup private components from @wordpress/components, refining the block highlighting, adding Gravatar default detection, and aligning the color system with collab-sidebar.

Why?

The collaborator overlay previously used custom avatar rendering and inline DOM manipulation. The cursor labels were rendered imperatively via a CursorRegistry class. The color system in @wordpress/core-data was different than the colors used in collab-sidebar and wasn't the best place for presentation concerns.

This PR:

• Replaces custom avatar rendering with the reusable Avatar component (badge mode for cursor labels, standard mode for presence list)
• Simplifies collaborator colors to use the same deterministic 8-color array as collab-sidebar (AVATAR_BORDER_COLORS)
• Moves BlockCanvasCover.Slot after WritingFlow so the overlay renders on top of editor content

How?

Avatar integration

• Cursor labels use Avatar in badge mode (name prop triggers hover-expand pill animation)
• Presence header uses AvatarGroup with max={3} for stacked avatar display with +N overflow
• Collaborators list popover uses Avatar with borderColor for each collaborator
• Compiled Avatar SCSS is injected into the editor iframe via useStyleOverride (since wp-components styles are excluded from the canvas iframe by the PHP REST controller)

JSX cursor rendering

• useRenderCursors now returns CursorData[] instead of imperatively creating DOM elements
• overlay.tsx renders cursors as JSX with Avatar badge labels
• Removed cursor-registry.ts and imperative DOM manipulation

Color simplification

• Editor consumers now use getAvatarBorderColor(userId) from collab-sidebar/utils.js (8 colors, userId % length)
• Same color used for avatar border, block highlight outline, and cursor label
• Removed color, strokeColor, backgroundColor from CollaboratorInfo type

Testing Instructions

Note: RTC collaboration features require a collaborative editing environment with multiple users connected to the same post via the sync provider.

1. Open a post in the editor with RTC/collaboration enabled
2. Have a second user connect to the same post
3. Verify the collaborator avatar appears in the header toolbar (stacked with +N overflow if >3 users)
4. Click the avatar group to open the collaborators popover — each user should show an avatar with colored border and name
5. Move the second user's cursor within a block — verify a colored cursor caret appears with a pill-shaped avatar badge that expands on hover to show the user's name
6. Have the second user select an entire block — verify the block gets a colored highlight outline matching the user's avatar border color
7. For users without a custom Gravatar, verify the avatar shows initials (first letter of first two words) instead of the default Gravatar placeholder

Testing Instructions for Keyboard

1. Tab to the collaborator avatars button in the header toolbar
2. Press Enter/Space to open the popover
3. Verify focus moves into the popover
4. Press Escape to close
5. Verify focus returns to the trigger button

Screenshots or screencast

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dabowman <davidabowman@git.wordpress.org>
Co-authored-by: chriszarate <czarate@git.wordpress.org>
Co-authored-by: maxschmeling <maxschmeling@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @dabowman! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/7.0 branch. Please resolve the conflict manually and create a PR to the wp/7.0 branch.

PRs to wp/7.0 are similar to PRs to trunk, but you should base your PR on the wp/7.0 branch instead of trunk.

# Checkout the wp/7.0 branch instead of trunk.
git checkout wp/7.0

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick cbda05fa088073ee9624ccec564d8c6c2d8fb4bc

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.0 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[t-hamano]

This PR is already in the wp/7.0 branch, so no backport label is needed.