Improve profiling output for repeated component names

profile slow と profile rerenders のプロファイリング出力パスを追跡し、ソースメタデータを提供する React DevTools の検査ペイロードから始めます。完了条件は、一致するソース ID を持つエントリのみをグループ化し、異なるエントリやメタデータのないエントリは分離したままにし、グループ化された各インスタンスについて親パスのコンテキストを保持することです。

Summary

Profiling views like profile slow and component-level reporting can be hard to interpret when the results include multiple repeated rows with the same display name, especially generic names such as Context.Provider.

Today the output is a flat list of component instances, so repeated names do not provide enough context to tell whether they are the same component reused in many places or different components that happen to share the same display name.

Problem

When profiling output contains repeated names:

• it is difficult to tell which entries are actually related
• Context.Provider-style rows are especially noisy because the name alone is not actionable
• users often need extra follow-up inspection to understand which subtree or implementation each row refers to

Suggested direction

Improve profiling output by grouping repeated entries only when they represent the same component implementation, not just the same display name.

A reasonable approach would be:

• preserve source metadata from React DevTools inspection payloads
• normalize a grouping key from source identity, such as fileName + line/column
• group repeated results in profile slow and profile rerenders only when that source identity matches
• include short hierarchy/path context for each grouped instance, so the result remains actionable
• keep components with missing source metadata as standalone rows rather than grouping heuristically by name

Expected behavior

• same display name + same implementation/source => grouped
• same display name + different implementation/source => separate entries
• missing source metadata => no grouping
• per-instance output should still show enough parent-path context to identify where each instance lives

Why this matters

This should make profiling output easier to act on without requiring extra manual inspection, especially for apps with many providers, wrappers, or repeated higher-order components.