feat: introduce product hierarchies so sub-features collapse onto their parent product

[DevSecNinja]

Goal

Introduce a notion of product hierarchies / parent-child relationships so that product features (e.g. Attack Simulation Training) collapse onto their parent product (Microsoft Defender for Office 365) consistently across the dashboard — most visibly in the Network view, but potentially anywhere products are listed.

Problem

Today, Attack Simulation Training appears as a separate product node in the Network map, when it is really a capability of Microsoft Defender for Office 365 (Plan 2). This over-counts the number of distinct products and is misleading.

The root cause is a naming-convention mismatch. The Network view already knows how to collapse sub-features onto a main product, but it relies on a specific " — sub-feature" separator:

// A product entry's name may carry a " — sub-feature" suffix (e.g.
// "Microsoft Purview Compliance Manager — DPIA templates"). Collapse those onto
// the main product so the graph shows one node per product.
function mainProductName(name) {
  return name.split(/\s+—\s+/)[0];
}

However, the Attack Simulation Training entry is named with a parenthetical parent instead of the — separator, so it is not collapsed:

{
  "name": "Attack Simulation Training (Microsoft Defender for Office 365)",
  "tier": "A5",
  ...
}

This likely affects other products too, wherever a capability is named in a way that doesn't match the — convention.

Acceptance criteria

1. Attack Simulation Training no longer renders as its own product node in the Network view; it is attributed to Microsoft Defender for Office 365.
2. The relationship between a feature and its parent product is captured explicitly in the data (not inferred from fragile string parsing).
3. The grouping is consistent across every place products are surfaced (Network nodes/links/legend, and any other product listings).
4. The full, human-readable feature name is still shown where the detail matters (e.g. the measure detail panel and tooltips), so no information is lost.
5. An audit of src/data/grip.json is performed to catch other products with the same problem (e.g. parenthetical parents or inconsistent naming).

Implementation suggestions

There are two broad approaches — please pick whichever fits the project's direction:

Option A — Explicit hierarchy in the data (preferred for robustness)

• Add an optional field to each microsoft entry, e.g. parentProduct (or product + feature), so a capability can declare its parent product explicitly.
• Update buildGraph() / mainProductName() in NetworkMapView.jsx to group by parentProduct when present, falling back to the current — split.
• Document the new field in CONTRIBUTING.md alongside the existing tier / a5Adds / addOn guidance.

Option B — Normalize naming to the existing convention (lighter touch)

• Rename the entry to use the existing separator, e.g. "Microsoft Defender for Office 365 — Attack Simulation Training", so the current mainProductName() logic collapses it automatically.
• Sweep the dataset for other parenthetical / inconsistent names and normalize them too.
• This is faster but keeps the grouping logic dependent on string conventions.

Relevant code

• Product grouping helpers: src/components/NetworkMapView.jsx (mainProductName, shortProductName, buildGraph)
• Mapping data: src/data/grip.json
• Where full names are rendered: src/components/MeasureDetailPanel.jsx
• Contributor guidance on mappings: CONTRIBUTING.md