fix(coding-conventions): Resolve static-component-definitions in progressActivityTooltip

[sentry]

This PR addresses a static-component-definitions violation reported in static/app/views/issueList/progressActivityTooltip.tsx.

Problem:
The ProgressActivityItem component was dynamically creating a React component type (Icon) during its render cycle. Specifically, for GroupActivityType.NOTE, the componentFunction in groupActivityIcons.tsx was returning a new inline arrow function (() => <StyledUserAvatar />) on every render. React interprets this as a new component identity each time, leading to unnecessary unmounting and remounting of the icon subtree, which is flagged by the React Compiler's StaticComponents diagnostic.

Solution:
To resolve this, a new module-scoped functional component, ActivityIcon, has been introduced in progressActivityTooltip.tsx. This ActivityIcon component now encapsulates the logic for determining and rendering the correct icon based on the item and iconMapping props. By making ActivityIcon a stable, module-scoped component, React always sees the same component type, even though the content rendered inside ActivityIcon might vary based on props. This ensures that the icon subtree maintains its state across renders and adheres to the static-component-definitions convention.

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

Fixes CODING-CONVENTIONS-36D

_{Comment @sentry <feedback> on this PR to have Autofix iterate on the changes.}